Accounts Interests and Charges PDF

TEMENOS T24
Accounts, Interest and Charges
User Guide
Information in this document is subject to change without notice.
No part of this document may be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without the express written permission of TEMENOS Holdings NV.
Copyright 2005 TEMENOS Holdings NV. All rights reserved.

Accounts Interests and Charges
Table of Contents
Introduction.............................................................................................................................................. 4
Application Overview ........................................................................................................................... 4
Client Account .................................................................................................................................. 4
Internal Accounts.............................................................................................................................. 7
Account Number Format .................................................................................................................. 8
Account Input ................................................................................................................................... 9
NOSTRO Accounts ........................................................................................................................ 12
Account balances ........................................................................................................................... 12
Locking of Funds (Blocked or Held Amounts)................................................................................ 33
Change of Main Customer ............................................................................................................. 36
Account Closure ............................................................................................................................. 37
Interest, Premium Interest, Charges And Statement Parameters ................................................. 42
Interest Calculation Overview ........................................................................................................ 44
Interest Capitalisation And Accrual ................................................................................................ 45
Daily Compounding Interest – Accounts ........................................................................................ 46
Compounding Interest in Other Applications ................................................................................. 46
Compounding Interest with non-Daily frequency ........................................................................... 46
Example of Daily Compounding Calculation in Accounts .............................................................. 47
Negative Interest ............................................................................................................................ 49
Bonus Interest ................................................................................................................................ 49
Interest Related Tax And Charges................................................................................................. 50
Account Maintenance Charges ...................................................................................................... 51
Offsetting And Waiving Charges .................................................................................................... 52
Limits .............................................................................................................................................. 52
Account Statements ....................................................................................................................... 52
Account Violations.......................................................................................................................... 53
Account Sweeping.......................................................................................................................... 55
Overview of Input and Processing ..................................................................................................... 59
Multi-Level Cash Pooling................................................................................................................ 59
Example ......................................................................................................................................... 68
Account before first sweep............................................................................................................. 69
Account after COB ......................................................................................................................... 70
Account after new postings ............................................................................................................ 70
Account after next COB.................................................................................................................. 71
Payment Netting............................................................................................................................. 78
Parameter Files .............................................................................................................................. 85
TEMENOS T24 User Guide Page 2 of 355

Internal Files................................................................................................................................. 133

INTEREST & CHARGES ................................................................................................................. 135
Interest & Charges ....................................................................................................................... 135
MINIMUM DEBIT INTEREST....................................................................................................... 159
CHARGES.................................................................................................................................... 172
Set-up of IC.CHARGE.PRODUCT............................................................................................... 191
Set-up of IC.CHARGE.................................................................................................................. 194
Set-up of Contingent Accounts .................................................................................................... 200
ENQUIRIES.................................................................................................................................. 211
ADVICES...................................................................................................................................... 215
FILES USED ................................................................................................................................ 215
END OF DAY ............................................................................................................................... 228
DELIVERY.................................................................................................................................... 232
CHEQUE ISSUE & MANAGEMENT ............................................................................................... 233
Cheque Issue & Management...................................................................................................... 233
Deposited Cheque Collection....................................................................................................... 250
Bulk Accrual of Interest and Charges........................................................................................... 282
Interest Compensation Accounts Hierarchy (ICA) ....................................................................... 288
GWHT (GERMAN WITHHOLDING TAX)GWHT (German Withholding Tax).............................. 307
TAX.GEN.CONDITION:- .............................................................................................................. 313
EXEMPTION ................................................................................................................................ 314
ACCOUNTING SET-UP ............................................................................................................... 320
Account Tax Computation Joint Holder wise ............................................................................... 323
HIGH VOLUME ACCOUNT PERFORMANCE................................................................................ 327
Introduction to high volume account performance ....................................................................... 327
SUB-ACCOUNT PROCESSING.................................................................................................. 328
CONSOLIDATION OF STATEMENT ENTRIES.......................................................................... 333
CONSOLIDATION OF CATEGORY ENTRIES ........................................................................... 345
ARCHIVING ................................................................................................................................. 345
STATEMENT PRINT MASKING .................................................................................................. 347
US REGULATION D COMPLIANCE .............................................................................................. 351
US Regulation D Compliance ...................................................................................................... 351
Account.Parameter....................................................................................................................... 352

Introduction
Application Overview
The ACCOUNT module (and its Interest and Charges routines) caters for the creation, maintenance
and control of all types of accounts handled by T24. It also provides:
• Calculation of interest on client accounts.

• Calculation of premium interest on client accounts.
• Calculation of charges relating to the maintenance and servicing of accounts.
• Pre-notification of debit interest and/or charges on client accounts.
• Production of statements, overdraft and referral reports.
Accounts can be classified as one of two types, client accounts or internal accounts. Client accounts
are those owned by an external customer such as current accounts, savings accounts etc. Internal
accounts are those owned by us such as suspense accounts.
There are no actual general ledger accounts in T24. To allow for accurate and detailed accounting
analysis, profit and loss balances are not held in an account, instead consolidated balances and
movements are kept at the lowest reporting level by use of specific category codes, which are used by
all applications to record profit and loss entries. The usage of these ‘virtual’ general ledger accounts is
explained in the Reporting chapter of the user guide.
Client Account
A client ACCOUNT can be one of many different types, a simple current account, overdraft or savings
accounts and many more. T24’s strength lies in the flexibility within which new account types can be
added to it in order to meet the bank’s ongoing requirements.
T24 is a customer-orientated system. An account is connected to a CUSTOMER record and thus the
owner and address details are not entered on the individual ACCOUNT. This eliminates the need for
extensive maintenance of customer information such as when a customer changes their address.
When T24 is installed, part of the implementation process is to configure the types of accounts the
bank wishes to offer and their characteristics. Typically this would include the debit/credit interest rates,
interest and charges capitalisation frequencies, statement production cycle, other account group
conditions etc. Once these key files are set up the addition of a new client ACCOUNT is very simple.
The processing options available on client accounts include:
• Posting Restrictions
• Referral Conditions
• Alternate Account ids

• Mnemonic codes
• Joint account holders
• Liquidation of interest to another account
• Pre-Notification of debit interest due
• Charges capitalised to another account
• Pre-Notification of charges due
• Interest and Charges settled in currencies other than the account currency
• Combining balances across accounts before interest calculations
• System information fields such as balances etc.
These options are detailed later in this guide.
An example of a simple current account is shown below:
Figure 1 Client Account

In the above example the account 25976 has a field MNEMONIC that contains a value of LDLEUR.
This mnemonic can be entered into any standard T24 ACCOUNT field and is translated automatically
into the correct ACCOUNT number.
A NOSTRO account is a special type of account, identified by the CATEGORY code and the
LIMIT.REF field containing the word “NOSTRO”. As it is a shadow of the VOSTRO account
maintained by the correspondent the client id is informational the real account owner is you. An
example of a NOSTRO account is shown below using the following function:
Figure 2 Nostro Account
When setting up a Nostro Account the client of the ACCOUNT should not receive a statement, or
debit/credit advices. These should be re-directed to your reconciliation’s department. Create a print re-
direct address for the correspondent (e.g. US0010001.C-100002.PRINT.2 on DE.ADDRESS) then in
DE.PRODUCT create a record for the Nostro Account (e.g. US0010001.A-26751.ALL.ALL) this will
prevent any advices for this account being sent to your correspondent.
If single limit field in ACCOUNT is set to “Y” then only one account can be attached to a limit record. If
set to “N” then multiple accounts are allowed to utilise a single limit. Single limit Y/N can be defaulted
from ACCT.GROUP.CONDITION using single limit default field. Single limit in account can also be
used independently without setting up ACCT.GROUP.CONDITION.

For information on the Reconciliation module, its capabilities and how it can assist your Reconciliation
Department in their daily workflow please refer to the User Guide chapter for that module.
Internal Accounts
Internal accounts are not related to a CUSTOMER record, and are used for maintenance of cash
accounts, accrued profits, suspense accounts, tax and capital accounts. Since there is no
CUSTOMER record related to internal accounts, details such as account title and short title need to be
specified when the account is created.
The account number of an internal account consists of the currency, category and a subdivision
number.
An example of a simple internal cash account, is shown below:
Figure 3 Internal Account

Account Number Format

T24 can use many different Account id structures. These can be any of the ones we supply or new
check digit types can be created on request. To match existing styles you can also apply an Account
mask, which makes it easier for the User to visualise the account’s structure.
Client format
The ACCOUNT number on client accounts is a number of up to 16 characters. The format of the
number can be validated if required, for example by the use of check digits or the automatic inclusion
of the CUSTOMER number.
The length and check digit type used for an account is defined in the COMPANY application, in the
fields:
ACCT.CHECKDIG.TYPE
ACC.BKNO.PREFIX
ACCOUNT.MASK
For extended account numbers longer than 16 characters, the input length must be defined in the
EB.OBJECT application, in the field MAX.LENGTH.
ACCT.CHECKDIG.TYPE Please refer to the HELPTEXT on these fields for the settings you require.
Identifies the check digit calculation method for the company being entered.
The following values will be accepted:
'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. The prefix may
contain leading zeros.
'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, and the second on the remaining
digits. The check digits are calculated using mod 11.
'99': No check digit calculation with the account number zero filled to the ACCOUNT.MASK.
'@routine name’: Where a local subroutine performs the check digit calculation.
'blank': in all other cases.
Note: Once a customer account record has been authorised in this company, this field may no longer
be changed.

Validation Rules
The following values will be accepted: '1', '2', '3', '4', '5', '6', '99', @routine name and 'blank'. Mandatory
input when LOCAL.CURRENCY starts with BE or LU.
Internal Format
The format of an internal account consists of the currency, the category code of the account and a
sequential number. This structure is shown below:
Figure 4 Internal Account ID Structure
Some fixed internal ACCOUNT records are required by T24 applications and must exist prior to
entering any transactions on these applications. These are listed in the ACCOUNT.CLASS records
and are detailed in the field RECORD.TYPE. It is recommended that the local currency account records
be input manually. T24 is able to open any foreign currency account required automatically, providing
that one exists for the specific account category.
The ACCOUNT will have the text ‘RECORD.AUTOMATICALLY.OPENED’ set in fields

ACCOUNT.TITLE.1; ACCOUNT.TITLE.2 and SHORT.TITLE, these can then be amended whenever
convenient.
Account Input
Customer Account input

Customer accounts are only opened manually. The ACCOUNT number of a customer account can
be up to 16 numeric characters, subject to local restrictions and requirements; such as check digit
validation.

Figure 5 Client Account
Some details such as the account title, customer who owns the account, CATEGORY and
CURRENCY, are input at this time. However, extensive ranges of characteristics are defined on
related parameters tables. This enables an ACCOUNT to be opened with a minimum of details
minimum of details required on input and majority of the processing characteristics defaulted from
group level parameters. Consequently, when these characteristics change, perhaps because of a
change in business policy, the modification need only be applied once to the group level parameter,
which automatically processes all the related ACCOUNT records with the new settings.
The types of characteristics that can be set up on the related parameters include:
• Interest rates and methods

• Interest capitalisation frequency
• Statement generation
• Charges
• Posting restrictions.
• Premium Interest rates methods and capitalisation frequency
• Other parameters defining validation rules for transactions over accounts

The majority of these parameters are linked to the account’s CONDITION.GROUP. The
CONDITION.GROUP defines the way the ACCOUNT is processed. It is set automatically by using
characteristics pre-defined by the user. For example the CONDITION.GROUP for a current account for
corporate clients may be different to that for private clients. This might mean that corporate clients
receive statements daily by default whereas private clients receive them monthly.
Generally these characteristics are defaulted by CONDITION.GROUP but they may be overridden for
particular accounts whenever required. For example, the default statement frequency for private
clients in the above example was monthly, however this could be set to weekly for a particular account.
Internal account input

Internal ACCOUNT records may be opened manually or automatically. The id of an internal account
consists of a CURRENCY, CATEGORY and a suffix.
Figure 6 Internal Account

NOSTRO Accounts
Nostro ACCOUNT records have a key in the same format as a customer ACCOUNT and the account-
servicing bank is treated as a CUSTOMER for most purposes.
Account balances
The following balances are held on the ACCOUNT record in T24.
OPEN.ACTUAL.BAL
This field contains the Actual Non-Cleared Balance or 'Ledger Balance' of the Account as at the start
of the day.
OPEN.CLEARED.BAL
This field contains the Cleared Balance of the Account as at the start of the day. This includes the
value of all entries over the Account except any credit entries or reversed debit entries with Exposure
Dates in the future.
For credit and reversal debit entries with Exposure Dates in the future, this field is updated in the start
of day processing on the appropriate date.
It is possible to split a single entry amount to clear in separate periods. This feature is called exposure
date splitting. For more information on this feature refer to the following sections in the user guide
(Local Clearing, Application Accounting, System Tables and Teller)
ONLINE.ACTUAL.BAL
This field contains the most up to date Actual Balance of the Account. This is the same as the actual
balance at the start of day (OPEN.ACTUAL.BAL) plus the value of all fully Authorised entries since
the start of day.
ONLINE.CLEARED.BAL
This field contains the most up to date Cleared Balance of the Account. This is the same as the
cleared balance at the start of day (OPEN.CLEARED.BAL) plus the value of all fully authorised entries
since the start of day excepting any credits or reversal debit entries with future Exposure Dates.

For credit and reversal debit entries with Exposure Dates in the future, this field is updated at start of
day processing on the appropriate date.
(Local Clearing, Application Accounting, System Tables and Teller).
WORKING.BALANCE
This field contains the present balance of the Account, which is used for checks done by the LIMITS
system in T24. At the start of day this figure will be the same as the cleared balance figure
(ONLINE.CLEARED.BAL).
For Nostros and Internal Accounts the field is updated by all accounting entries when they have been
fully authorised. For other Customer Accounts it is updated by debit entries when they are Validated
and by credit entries when they have been fully Authorised excepting for any credit or reversal debit
entries with Exposure Dates in the future.
For credit and reversal debit entries with Exposure Dates in the future, this field is updated in start of
day processing on the appropriate date.
(Local Clearing, Application Accounting, System Tables and Teller).
AVAILABLE.BALANCE
Through the Available Funds functionality, T24 will identify if any movements or transactions will
generate a deficit of cash in a client account or accounts, and will anticipate the impact of a new
transaction on pre-existing client commitments.
DATES
The date updated in the available funds ladder will be selected in the following order of date fields on
the contract resulting in the credit transactions:
1) EXPOSURE.DATE
2) VALUE.DATE if exposure date is blank
3) BOOKING.DATE if value date is blank
While for debit transactions the following order is applied:
1) VALUE.DATE

2) BOOKING.DATE if value date is blank
Exposure Date
The exposure date is the date on which a credit entry is included in the cleared balance of an account.
Value Date
The value date is the date from which the entry is included for calculation of interest. Where there is
no exposure date on the transaction the value date is used as the date which the transaction affects
the available funds.
Booking Date
The booking date is the date on which the transaction has been processed.
Available Funds Window

Available funds balances are held for all forward dated and value dated account movements up to the
number of calendar days forward from today as specified on CASH.FLOW.DAYS in
ACCOUNT.PARAMETER.
EXAMPLE:
If today’s date is 13th of April 2000, and CASH.FLOW.DAYS is set to 10 then:
Window start date will be 13th April 2000

Window end date will be 23rd April 2000

Figure 7 Account Parameter showing the cash flow window
Any transaction with an exposure date or value date within that period will be included in the available
funds ladder.
Transactions beyond the Window

Any value dated transactions (e.g. Data Capture, Funds Transfer and Teller) with exposure date or
value date beyond the window will cause the window to expand for that account.
As a consequence of this, any forward dated transactions (e.g. Money Market, Loans) with a value
date beyond the window will automatically be included in the available funds ladder.
Backdated transactions
Any transactions with a value date or exposure date less or equal to today’s date will be held under
today’s date available funds ladder.
Example of a backdated transaction and a transaction beyond the window on the following account:

Here is the account before a back-valued transaction is entered:
Figure 8 Existing account before back-valued transaction entered
We then enter (and authorise) a back-valued funds transfer, which has the effect of debiting this
account:

Figure 9 Enter funds transfer to debit account
The account now shows a debit movement and balance in the available funds fields, with the value
date of today:

Figure 10 Account after debit payment has been passed
MOVEMENTS
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 or unauthorised debits or both of them or even neither of them.
All the movements will be held as follows unless a restriction has been set in EB.AF.PARAM at
transaction or application level:
AV.AUTH.DB.MVMT - authorised debits

AV.NAU.DB.MVMT - unauthorised debit movements
AV.AUTH.CR.MVMT - authorised credits
AV.NAU.CR.MVMT - unauthorised credits

More details on EB.AF.PARAM are described below.
BALANCES
Open Available Balance

The available balances are built using the OPEN.AVAILABLE.BAL as the starting balance. At the
start of day the OPEN.AVAILABLE.BAL consists of all authorised debits with value date less or equal
today plus all authorised credits with an exposure date less or equal today (excluding contract entries,
such as the principal draw down of a loan valued today).
Available Balance
The AVAILABLE.BAL always includes authorised debits and credits. The parameterisation regarding
the update of available balances with unauthorised entries takes place as follows via
AVAILABLE.BAL.UPD:
ACCOUNT.PARAMETER
BOTH - Unauthorised debits and credits to make up available balance

NONE - No unauthorised movements to update available balance
DEBITS - Only unauthorised debits to make up available balance
CREDITS - Only unauthorised credits to make up available balance
This option is also available at ACCT.GROUP.CONDITION and ACCOUNT level.
It is also be possible to set the conditions for all accounts linked to a portfolio at SEC.ACC.MASTER
level, in this case the individual accounts linked to the portfolio will be updated.
Note: If unauthorised debits/credits are excluded from the AVAILABLE.BAL, the movements
will still be updated unless they have been blocked in EB.AF.PARAM.
Credit Checking
A 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 options are as
follows:
• Null or WORKING - check overdraft and cash flow

• AVAILABLE - perform an available funds check

This option is also available in the ACCT.GROUP.CONDITION, SEC.ACC.MASTER and ACCOUNT

application in the following order:
• ACCOUNT – a flag set here always takes precedence over a flag set elsewhere.
• SEC ACC.MASTER. (If the account is linked to a Portfolio and if ACCOUNT is blank).
• ACCT.GROUP.CONDITION (If ACCOUNT is blank, if account is not linked to a portfolio and
SEC.ACC.MASTER is blank).
• ACCOUNT.PARAMETER (If all of the above applications have not been set).
If set to AVAILABLE then all credit checks will be made against the Available Balances and Cash
flows and Working Balance will be ignored although the Cash flows movements are still populated to
the account.
If an account is linked to a limit then a limit check will take place, otherwise an available balance check
will take place.
If an account is linked to a Shared Balance then a Shared Balance check will take place, otherwise an
available balance check will take place.
NOTE: If an account is a member of a shared balances group then it cannot be linked to a limit.
The AVAILABLE.BAL used for credit checking will be made up of the movements as defined by
AVAILABLE.BAL.UPD.
Override Messages
Available Balance Excess

An Available Balance Excess override message will be raised if an account is linked to a limit and an
on-line debit transaction has caused the overdrawn available balance on value date of the transaction
to exceed its Limit.
Available Balance Overdraft

An ‘AVAILABLE.BALANCE.OVERDRAFT’ override message will be raised if an account is neither
linked to a Limit nor to a Shared Balance pool and if an on-line debit transaction will cause the
available balance to negative as of the value date of the transaction.
Available Cash Pool Overdraft

An ‘AVAIL.POOL.OVERDRAFT’ message will appear if an on-line debit transaction for a particular
account associated with a pool of accounts causes the combined balances of all the accounts in that
group to go into overdraft.

Parameters
EB.AF.PARAM
This application defines the blocking parameters of unauthorised transactions to the available funds
movements. The blocking may be set at application level or at transaction level within an application.
The application has to be a valid record id in EB.SYSTEM.ID.
A blocking at transaction level within an application will take priority over whatever is set for that
application level.
In the function below, blocking parameters have been set for all unauthorised credits and debits within
DC (DATA.CAPTURE).
Figure 11 EB.AF.PARAM showing the available funds parameter set for Data Capture
If an unauthorised transaction is blocked, then neither the movements nor the available balance will be
updated and also no credit check is made for that transaction.
The parameters present in this application are the ones that will be used for blocking unauthorised
transactions for available funds processing. Any change to these parameters must be made through
EB.AF.PARAM.CHANGE.
EB.AF.PARAM.CHANGE

This application allows the input of blocking parameters for available funds processing for an
application.
Fields AVAIL.BAL.NAU.DR and AVAIL.BAL.NAU.CR are used to define the blocking for the
application.
In the example below, blocking parameters have been set for DC
Figure 12 Available Funds Parameter Change for Data Capture
From the example
Application
The first two fields define the blocking parameters for the application
• Having the field AVAIL.BAL.NAU.DR set to blank means that all unauthorised debits for DC
should update the available funds movements and the available balances and also credit check
should be made.
• Having the field AVAIL.BAL.NAU.CR set to ‘NO’ means that none of the unauthorised credits
for DC should update either available funds movements or available balances.
Transaction

If a blocking parameter that is different from what has been set for the application needs to apply for a
transaction code, then these parameters need to be set under the transaction code.
In the above example, any DATA.CAPTURE entered which uses transaction code 1 (Miscellaneous
Debits) will be blocked from updating any unauthorised debits.
All other transaction codes used in DATA.CAPTURE will take the blocking parameters set for the
application.
If the field AVAIL.NAU.DR were set to ‘NO’ then no unauthorised Miscellaneous debits in
DATA.CAPTURE would update the available funds movements and the available balances. As a
result, no credit checking would be made for that unauthorised transaction.
Effective Date
The Effective Date field defines the date at which the parameters take effect, by default it will take
today’s unless the date a future date is input.
Once the parameters have been set in EB.AF.PARAM.CHANGE, depending on the effective date,
they will be written to the EB.AF.PARAM during the end of day.
ACCOUNT, SEC.ACC.MASTER, ACCT.GROUP.CONDITION and ACCOUNT.PARAMETER
Two parameters may be set at ACCOUNT level or ACCT.GROUP.CONDITION or

ACCOUNT.PARAMETER for the available funds processing:
CREDIT.CHECK
This field defines on what balance credit check is to be made, the possible values are:
• WORKING or NULL (blank) - the default indicates that both overdraft and cash flow checks, no
credit check, will be made on Available balances.
• AVAILABLE indicates that only the available funds check is made against the available funds
balance fields. This will take place from the value date of the transaction to the end of the cash
flow window.

Figure 13 Credit Check set to Account Level
AVAILABLE.BAL.UPD
This field defines which unauthorised movements are included in the AVAILABLE.BAL field that will
be used for credit checking:
BOTH indicate that both unauthorised debits and credits are included in the Available
Balance.
NONE indicates that no unauthorised debits or credits are included in the Available Balance.
DEBITS indicate that only unauthorised debits are included in the Available Balance.
CREDITS indicate that only unauthorised credits are included in the Available Balance.

Figure 14 Available Bal Upd set at Account Level
The following order will apply:
• ACCOUNT
• SEC.ACC.MASTER (If the account is linked to a Portfolio and if ACCOUNT is blank).
• ACCT.GROUP.CONDITION If ACCOUNT is blank, if account is not linked to a portfolio and
SEC.ACC.MASTER is blank).
• ACCOUNT.PARAMETER (If all of the above applications have not been set).
Exceptions
EB.AVAILABLE.FUNDS.WORK
This work file is updated during the start of day processing to store information pertaining to all
accounts with negative available funds balances as of the beginning of the day.
Any required reports will be developed locally using the data in this work file.

Figure 15 EB.AVAILABLE.FUNDS.WORK showing account with negative available

balances
This file is keyed on account number and it contains the following information:
• Customer number
• Sector
• Account officer
• Currency of the account
• Portfolio number if applicable
• Last working day
• Previous days open available balance
• Previous days local equivalent of open available balance
• A multi valued set of previous days information related to negative available balances
• Multi valued previous days available date
• Multi valued previous days available negative balance
• Multi valued previous days local equivalent of negative balance
• Current working day
• Current days open available balance
• Current days local equivalent of open available balance

• A multi valued set of current days information related to negative available balances
• Multi valued available date
• Multi valued available negative balance
• Multi valued local equivalent of available negative balance
If there are no negative available balances within the cash flow period for the current day, then the
record is deleted, otherwise amounts for the current working day and the previous working day are
maintained.
The AVF.WORK.UPDATE job within FILE.TIDY.UP batch takes care for the maintenance of the
EB.AVAILABLE.FUNDS.WORK by removing the accounts that no longer have negative available
balances.
Available Funds Exception
This work file gives a list of accounts with an overdrawn available balance or that have exceeded their
limit due to any forward entries that have fit into the Available funds window during the Start of Day.
Rebuilding Available Funds
In order to use the available funds functionality, the available funds ladder must be built for accounts
with existing future transactions, otherwise only new transactions will be reflected in the available
funds.
An option exists in the FILE.TIDY.UP batch, namely REBUILD.AVAIL.FUNDS to rebuild the available
funds ladders for each account.
The job will be run as part of the Start of day process. If the job is to be run the frequency of the job in
the batch needs to be changed.

Figure 16 BATCH ENTRY showing the jobs under FILE.TIDY.UP
This process is very time consuming and may impact on the start of day process. Once the start of
day is over, the REBUILD.AVAIL.FUNDS task should be set to ‘A’.
This task may also be run in case of data corruption in available funds.
Available Funds and Shares Balances
If an account is a member of a shared balances group then an exposure-dated ladder will be

constructed using the combined balances of all the accounts in the group. The combined exposure
dated ladder will consist of a combination of all the available balances for every account associated
with that group. When an online debit transaction takes place then the ladder will be updated with the
transaction amount for the appropriate date. The system will then check to make sure that there is an
overdraft. If so, then an override message will be generated.
Set up Cash Pooling for Available Funds
The first part is to set-up the AC.CP.GROUP.PARAM file with some sort of cash pooling id. The
MAIN.MASTER field must consist of the main account number for the cash-pooling group.

Figure 17 AC.CP.GROUP.PARAM record
Once the AC.CP.GROUP.PARAM record has been set-up, the next phase would be to set-up the
AC.CASH.POOL record. The id must be the main master account number and all the accounts linked
to the particular group must be set-up under the LINK.ACCT field.
When fields such as BACK.VALUE.ADJ BACK.VALUE.CAP BALANCE.TO.USE & SUB.GROUP are
amended any underlying records relating to that AC.CP.GROUP.PARAM will have the field
LAST.MAINT.DATE on AC.CASH.POOL UPDATED to today’s date. This is because the terms of
the sweep have been altered and back valued adjustments would not follow the same rules as were
previously in place before the changes.

Figure 18 - AC.CASH.POOL record
Once the two cash pooling files have been set-up with the group ids, the SB.GROUP.ID field for all
the accounts linked to that particular group will be updated with the cash-pooling id. Please note, if you
are doing an overdraft check on the combined balances of available funds then please make sure that
the CREDIT.CHECK field of the account has been set to AVAILABLE.

Figure 19 - Account record with SB.GROUP.ID filed
When a transaction of some sort is passed through to an account that is linked to a cash pool, the
system will then get all the available balances of all the accounts linked to that same cash pool and
combine them to create an available funds exposure dated ladder. Once the ladder has been created,
the system will locate the date of the transaction on the ladder and then sift through all the combined
balances, displaying the highest overdraft as an override. Below is an example of an overdraft for a
group of combined available fund balances.
Date ACCOUNT A ACCOUNT |B ACCOUNT C

Opening Bal -1000.00 0.00 1000.00
03/03/02 -2000.00 1000.00 3000.00
04/03/02 -2000.00
05/03/02 1000.00 -3000.00
06/03/02 1500.00 1000.00
07/03/02 -4000.00
08/03/02 1000.00 -3000.00
09/03/02 -3000.00

10/03/02 5000.00
11/03/02 -1000.00
12/03/02 7000.00 0.00
A Funds Transfer transaction is then passed to ACCOUNT a value dated 07/03/02 for 10,000.00
debits.
Date ACCOUNT A ACCOUNT B ACCOUNT C

Opening Bal -1000.00 0.00 1000.00
03/03/02 -2000.00 1000.00 3000.00
04/03/02 -2000.00
05/03/02 1000.00 -3000.00
06/03/02 1500.00 1000.00
07/03/02 -10000.00 -4000.00
08/03/02 -9000.00 -3000.00
09/03/02 -13000.00
10/03/02 5000.00
11/03/02 -1000.00
12/03/02 7000.00 0.00
Table of balances after 10000 FT debit to ACCOUNT A
Once the transaction is processed the available balances for ACCOUNT A, ACCOUNT B and
ACCOUNT C will be combined to created an available funds date exposure ladder as seen below.
DATE COMBINED
Opening balance 0.00

03/03/04 2000.00
04/03/02 -1000.00
05/03/02 1000.00
06/03/02 -500.00
07/03/02 -17000.00
08/03/02 -15000.00
09/03/02 -19000.00
10/03/02 -11000.00

11/03/02 -9000.00
12/03/02 -6000.00
Table showing combined balances for ACCOUNT A, B and C.
When the date exposure table has been created, the system will then look at all the combined
available balances from the 07/03/02 onwards and find the highest overdraft amount. In this example
the highest overdraft amount is on the 09/03/02, so therefore an overdraft message will be displayed
for the user, showing the date, group id, account number and the amount of –19000.00.
Locking of Funds (Blocked or Held Amounts)

T24 has the functionality to lock funds on an Account (also known as blocked or held amounts).
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.
The locked amount was previously input directly to the Account record but now each locked amount is
input as a separate event.
This is achieved through use of the application AC.LOCKED.EVENTS. This application must be
populated with the required details as follows:
ACCOUNT.NUMBER – the Account Number that will have the locked amount.
FROM.DATE – the date the locked amount will commence.
TO.DATE – the final date the locked amount will be held. Funds will be release as from the start of
the following day. If the field is left blank then the locked event will stay forever in the account until the
event is manually reversed.
LOCKED.AMOUNT – the amount of funds to be reserved for the above period.

Figure 20 - AC.LOCKED.EVENTS INPUT
The ACCOUNT application shows a ladder of locking events applied to that account, and will
automatically include a locked event of zero amounts starting from the date following the last TO.DATE
in any AC.LOCKED.EVENTS record applicable to that account.

Figure 21 - Account after authorised locked event
Note: Since the TO.DATE field was left blank, then no zero locked amount item is added to the
ladder to show the maturity of the event.
If there is an existing locking event applied to an account, then any new AC.LOCKED.EVENTS record
that covers all or part of the same period will result in the locked amount for the common dates in the
ladder being the sum of the LOCKED.AMOUNT fields for those periods.
Credit Checking
Exact functionality of this feature will depend on whether credit checking is being undertaken based on
the WORKING.BALANCE or the AVAILABLE.BALANCE of the account.
Credit checking against a locked amount is done at the input of a locked event and any transaction
that affects WORKING.BALANCE or AVAILABLE.BALANCE.
Which balance is being checked depends upon the input into field CREDIT.CHECK on ACCOUNT,
ACCT.GEN.CONDITION, SEC.ACC.MASTER or ACCOUNT.PARAMETER.

Working Balance
If this field is set to NULL or WORKING then the system will use the worst-case scenario. The
working balance will be checked against the highest amount in the locking ladder only and an override
generated as applicable.
Available Balance
Single Accounts
If the field is set to AVAILABLE then the system will check all of the available balances within the
available funds ladder against the locked events ladder and override messages generated accordingly.
Group Accounts
If an account forms part of a Cash pool, then an aggregated locked amount ladder is built in and the
group aggregated available balance ladder is checked against the group aggregated locked amount
ladder.
It should be noted that the override ONLY displays that the account will fall below the
LOCKED.AMOUNT and not the actual amount by which the account is short.
Matured Locked Events

On the start of day following the TO.DATE of the locked event, the matured locked event will be
written to history and deleted.
Hence the Account record will be updated accordingly and will no longer hold that locked amount.
Conversion of Existing Accounts

The accounts with existing locked amounts will be converted such that each existing locked amount
will be mapped to a locked event.
If a locked amount was set without any start date, the conversion date is used and no maturity is set to
locked event. Thus the locked amount will be held permanently in the account unless the event is
manually deleted or changed.
A history record of the account prior to change is held in the system.
Change of Main Customer

It may be required that the customer in an ACCOUNT record needs to be modified with that of another
customer, in cases like death of the main customer in an ACCOUNT record with JOINT.HOLDER.
T24 allows modification of the main CUSTOMER.ID for an ACCOUNT record with JOINT.HOLDER

to any one of the existing JOINT.HOLDER in the ACCOUNT record does not allow modification of
the main customer if there are limits linked to the customer.
Modification of the main customer is validated against the CATEGORY range as defined in
ACCOUNT.PARAMETER application under the record SYSTEM. The following screen shot shows the
example set-up of CATEGORY range in ACCOUNT.PARAMETER.
Figure 22 ACCOUNT.PARAMETER
Modification of the main CUSTOMER.ID for an ACCOUNT record with a single holder is allowed only
for NOSTRO type of accounts, even if the NOSTRO CATEGORY range is specified in the
ACCOUNT.PARAMETER application.
Account Closure
It is possible to close an account both Online and during the Close of Business.
The application ACCOUNT.CLOSURE is used to close accounts wither online or during the close of
business. The account number is used as the record id, and the system will calculate outstanding
interest, premium interest and charges. You may amend the capitalisation date, settlement account
and the posting restriction to be placed on the account record
The example screen below shows the ACCOUNT.CLOSURE record where the account will be closed
during the Close of Business:

Figure 23 Account closure
Interest and Charges are calculated on the value dated 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.
When an account is flagged for closure, any entries over the account require an override.
During end of day processing the following working day, if the OPEN.ACTUAL.BAL and
OPEN.CLEARED.BAL are both zero, the account is closed.
If it is required to close the account online then the field CLOSE.ONLINE should be set to Y. In
addition to this the user must decide which application will be used to pass the entries, which will settle
the account. FUNDS.TRANSFER, TELLER or ACCOUNT.CLOSURE can be used to pass these
entries. The field CLOSE.MODE will accept FT, TELLER or NULL, if NULL is specified then
ACCOUNT.CLOSURE will be used. Once the ACCOUNT.CLOSURE record is authorised the system
will raise the relevant entries and move the account record to history.
If FUNDS.TRANSFER is used after the ACCOUNT.CLOSURE record is input the system will
automatically raise an FT record and place it on hold, the id of the FT is stored in the field FT.ID.
Once the FT has been authorised, and the OPEN.ACTUAL.BAL and OPEN.CLEARED.BAL are both

zero, the ACCOUNT.CLOSURE record should be authorised and the account is closed and moved to
history.
If Teller is specified in the ACCOUNT.CLOSURE record, the system raises a TELLER.DEFAULT
record the ID of record is the ACCOUNT number, this record holds information that will be used in the
TELLER transaction which will pass the entries. The user is required to input a TELLER record, the ID
of the TELLER.DEFAULT record should be populated in the OUR.REFERENCE field of the TELLER,
(once the TELLER.DEFAULT record has been processed it can not be reused), and this will then
populate the transaction with details from the ACCOUNT.CLOSURE. Once the TELLER is authorised
and the OPEN.ACTUAL.BAL and OPEN.CLEARED.BAL are both zero, the ACCOUNT.CLOSURE
record should be authorised, and the account will closed and move to history.
Below is an example where Teller is being used to close an account online.
Figure 24 ACCOUNT.CLOSURE – with ONLINE set to Y and closure Mode is Teller

Figure 25 TELLER.DEFAULT record created by ACCOUNT.CLOSURE

Figure 26 An example TELLER – used to pass settlement entries
The system will not allow an account to be closed if it meets one of the following criteria
• Part of a SAM
• Direct Debit

• If it is a liquidation account
• Interest compensation account
• Charge account
• All-In-One account
• Part of a sweep account
• Part of a cash pool
• Not in current company
• Part of collateral
• Unauthorised AC.PENDING exists
• Blocked using AC.BLOCK.CLOSURE
• Closure should not be flagged when account is in suspense
Interest, Premium Interest, Charges And Statement Parameters

When an ACCOUNT is opened a number of characteristics related to the processing of interest,
premium interest, charges, and statements are defined using a flexible series of parameters. These
parameters are linked to the account’s CONDITION.GROUP.
The CONDITION.GROUP is assigned automatically using information in the fields specified in

CONDITION.PRIORITY. For example you can specify that the account processing characteristics (i.e.
the CONDITION.GROUP) are to be set on the basis of the SECTOR of the client and the CATEGORY
code of the account being opened. This would enable different account types for, based on the kind of
client. This would be set on the CONDITION.PRIORITY table.
Whenever an ACCOUNT is opened, T24 assigns a CONDITION.GROUP to the ACCOUNT depending

on the criteria specified in the ACCT.GEN.CONDITION table. The CONDITION.GROUP defines the
type of processing that T24 will perform on the account.
A wide range of other parameters are then linked to this processing group defining the processing for
the account such as when interest is to be applied, how often statements are to be produced, how
charges are to be levied on the account etc.
Often these specifications may be overridden for a particular account. For example the
GROUP.DEBIT.INT parameter specifies the debit interest rate to be applied by default to all the
ACCOUNT records in that CONDITION.GROUP. However if the debit rate for a particular account
needs to be different then a record will be entered on the ACCOUNT.DEBIT.INT table.
The structure of table’s controlling interest, charges and statements is shown below.

Figure 27 - Account Interest, Charges and Statements files

Figure 28 - Group settings for Accounts
Interest Calculation Overview

The Interest and Charges module using the following parameters control interest calculation in the
Account module is explained in more detail in the latter part of this chapter.
GROUP.DEBIT.INT
GROUP.CREDIT.INT
ACCOUNT.DEBIT.INT
GROUP.DEBIT.INT , GROUP.CREDIT.INT , ACCOUNT.DEBIT.INT , ACCOUNT.CREDIT.INT

Interest may be calculated on a daily, average, or highest/minimum balance basis using value dated
balances.
The movements/balances on different accounts in the same currency can be combined and interest
calculated on the net result.
Rates can be fixed or linked to basic rates plus or minus a margin.
Different rates can be specified for different balance levels and may be linked to the same or different
basic rates. The rates may apply to the whole of the balance or to the part between two balance levels.
Using group level conditions, it is possible to use the limits on individual accounts as the first level for
debit interest so that one rate can be charged up to the limit on any account and another rate when
the limit has been exceeded.
Interest can be calculated on a 366/365,366/364, 366/360, 360/365, 366/366, 360/366 or 360/360

days basis.
Back valued entries generate automatic adjustments to previously calculated interest.
For any accounts where interest conditions or rates are changed with effect prior to the last interest
application, the system generates adjustments on request.
Interest Capitalisation And Accrual

Interest capitalisation and accrual for the ACCOUNT module is controlled by the Interest and Charges
module using the following parameters:
GROUP.CAPITALISATION , ACCT.CAPITALISATION , ACCT.INTERIM.CAP

GROUP.CAPITALISATION
ACCT.CAPITALISATION
ACCT.INTERIM.CAP
ACCT.GROUP.CONDITION
Interest may be capitalised daily, every business day, every 1-9 weeks, twice a month (on the 15th and
the last day of the month) or every 1-99 months (using any day of the month). The capitalisation dates
can be specified at group or account level. Cycles may be different for debit and credit interest.
Special interim capitalisation may be requested without affecting the regular cycle.

Field 35 CORR.AT.CAP.DATE in ACCT.GROUP.CONIDTION allows the system, if functionality is

switch to “yes”, to capitalise interest on back-value dated entries to the next scheduled capitalisation
date, and not the back-valued date once the End of Day has been run.
It is possible to accrue interest normally on a monthly basis and specify certain types of accounts with
daily accrual.
Daily Compounding Interest – Accounts

Standard practice in the US for certain account based products is to calculate interest
using a daily compounding formula. See compounding interest with non-daily
frequency for details of formula.:
Interest for debit and credit accounts is calculated separately.
If an account goes to zero or the minimum balance for a credit account it will earn no
interest until the balance goes back above the minimum figure. Similar rules apply for
debit interest calculations.
Compounding Interest in Other Applications

All interest bearing applications will be required to support compounding interest
calculations.
Compounding Interest with non-Daily frequency

An additional requirement from the Canadian market is to support compounding
interest calculations where the frequency of compounding is not daily. The
compounding frequency can be typically one of the following:
Daily – Interest is compounded 365/6 times a year
Annual – Interest is compounded once per year
Semi-Annual – Interest is compounded 2 times a year
Quarterly – Interest is compounded 4 times a year
Monthly – Interest is compounded 12 times a year
Bi-Monthly – Interest is compounded 6 times a year
Twice-Monthly – Interest is compounded 24 times a year
Weekly – Interest is compounded 52 times a year
Bi-Weekly – Interest is compounded 26 times a year
The number of compounding periods in the year is used in a general formula to
provide a factor when calculating the effective interest rate, it is not necessary to
perform calculations split by the compounding frequency. The formula used is as
follows:
First an effective interest rate (EIR) is calculated using the specified rate:
EIR = (1 + NR / m)m -1

Where:
NR – Nominal Interest Rate, i.e. the rate defined
m – Number of times interest is compounded per year
This is then used to calculate the daily interest amount (DIF):
DIF = (1 + EIR)1/DIY -1
Where:
DIY = Number of days in the year (denominator of the day basis)
The interest amount for a period is then calculated as:
Int = (1 + DIF)D * (P + ITD)
Where:
D – Number of days in the calculation period
P – Principal
ITD – Interest calculated to date since the last application of interest
This formula can also be used for the calculation of daily compounding interest
Example of Daily Compounding Calculation in Accounts
ACCC.ACCT.CR
1 PERIOD.FIRST.DATE 03 NOV 2003

2 PERIOD.LAST.DATE 30 NOV 2003
3.1 CR.INT.DATE 03 NOV 2003
4.1 CR.NO.OF.DAYS 3
5.1 CR.VAL.BALANCE 1,000,000.00
6.1 CR.INT.RATE 5
7.1 CR.INT.AMT
4.2 CR.NO.OF.DAYS 4
5.2 CR.VAL.BALANCE 500,000.00
6.2 CR.INT.RATE 5
7.2 CR.INT.AMT
4.3 CR.NO.OF.DAYS 1
5.3 CR.VAL.BALANCE 1,500,015.00
6.3 CR.INT.RATE 5.25
7.3 CR.INT.AMT
20 TOTAL.INTEREST
Compounding: DAILY
Interest Basis: Actual/360

365
 0.05 
EIR5.00 = 1 +  − 1 = 0.0512675
 365 
DIF5.00 = (1 + 0.0512675)
1
360 − 1 = 0.000138889
365
 0.0525 
EIR5.25 = 1 +  − 1 = 0.0538986
 365 
DIF5.25 = (1 + 0.0538986)
1
360 − 1 = 0.000145833
Therefore:
( )
CR.INT . AMT7.1 = (1 + 0.000138889 ) − 1 * (1,000,000) = 416.72
3
= ((1 + 0.000138889 ) − 1)* (500,000 + 416.72) = 278.07

4
CR.INT . AMT7.2
= ((1 + 0.000145833) − 1)* (1,500,015 + 416.72 + 278.07) = 218.85

1
CR.INT . AMT7.3
Example :
The account in this example has a positive balance throughout the month.
1 PERIOD.FIRST.DATE 01 JAN 2004

2 PERIOD.LAST.DATE 31 JAN 2004
3.1 CR.INT.DATE 01 JAN 2004
4.1 CR.NO.OF.DAYS 5
5.1 CR.VAL.BALANCE 1,000,000.00
6.1 CR.INT.RATE 5
7.1 CR.INT.AMT
4.2 CR.NO.OF.DAYS 20
5.2 CR.VAL.BALANCE 1,500,000.00
6.2 CR.INT.RATE 5
7.2 CR.INT.AMT
4.3 CR.NO.OF.DAYS 6
5.3 CR.VAL.BALANCE 2,000,000.00
6.3 CR.INT.RATE 5.5
7.3 CR.INT.AMT
20 TOTAL.INTEREST
To determine interest accrual for each multi-value set, we apply the formula as follows:
 r d
i = (P + I )1 +  −P
 n
Multi-value set 1:

5
 0.05 
I = 1,000,0001 +  − 1,000,000 = 694.64
 360 
Multi-value set 2:
20
 0.05 
I = (1,500,000 + 694.64)1 +  − (1,500,000 + 694.64) = 4174.10
 360 
Multi-value set 3:
6
 0.055 
I = (2,000,000 + 694.64 + 4,174.10 )1 +  − (2,000,000 + 694.64 + 4,174.10) = 1,838.50
 360 
The results would then be as follows:
1 PERIOD.FIRST.DATE 01 JAN 2004

2 PERIOD.LAST.DATE 31 JAN 2004
4.1 CR.NO.OF.DAYS 5
5.1 CR.VAL.BALANCE 1,000,000.00
6.1 CR.INT.RATE 5
7.1 CR.INT.AMT 694.64
4.2 CR.NO.OF.DAYS 20
5.2 CR.VAL.BALANCE 1,500,000.00
6.2 CR.INT.RATE 5
7.2 CR.INT.AMT 4,174.10
4.3 CR.NO.OF.DAYS 6
5.3 CR.VAL.BALANCE 2,000,000.00
6.3 CR.INT.RATE 5.5
7.3 CR.INT.AMT 1,838.50
20 TOTAL.INTEREST 6,707.24
Negative Interest
It is possible to set negative interest rates on accounts in credit. To do this, the NEGATIVE.RATES
field on either ACCOUNT.CREDIT.INTEREST or in GROUP.CREDIT.INTEREST must be set to Yes.
If the field is set as either “No” or left unpopulated, then when interest rates fall below 0, zero interest
will be accrued to that account. Negative interest rates may occur either as a result of a negative rate
being directly entered into the CR.INT.RATE field or by a CR.BASIC.RATE being specified, and then a
discount being placed, which is greater than the CR.BASIC.RATE itself.
Bonus Interest
It is possible through fields on the GROUP.CREDIT.INTEREST and ACCOUNT.CREDIT.INTEREST
application to allow for the setting of a minimum value for account balances so that if the balance falls

below this value at any time during the capitalisation period no credit interest will be paid. The fields
CR.ZERO.INT.BAL and CR2.ZERO.INT.BAL in the above applications hold the value which if the
balance falls below, any time during the capitalisation period, then no interest will be paid. The fields
CR.ZERO.INT.OC and CR2.ZERO.INT.OC, in the same applications, allow for the setting whereby
if an account is opened or closed anytime during the capitalisation period then dependant upon the
input into these fields will determine whether or not interest will be paid.
Figure 29 - Bonus Interest fields
Interest Related Tax And Charges

Charges and taxes in the ACCOUNT module are controlled by the Interest and Charges module.
Tax on interest is calculated at application time and is controlled using the TAX application.
Certain additional charges based on the debit interest application may be applied on the same date,
these include:
Figure 30 - Interest related Tax and charges

Account Maintenance Charges

The Interest and Charges module controls all maintenance charges in the ACCOUNT module.
Account maintenance charges may be levied monthly, quarterly or six monthly, always at the end of
the appropriate month. The same capitalisation cycle is used for all types of account.
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 account was opened instead, a flag viz.
CHARGE.FIRST.MONTH must be set to a value of ‘YES’ on the ACCOUNT.PARAMETER application.
There are many main types of charges as follows:
Figure 31 - Account Maintenance Charges
Charges may be combined into one account entry or applied separately. Free, minimum and
maximum amounts can be specified for each charge. Separate charges can be defined for specific
currencies and local currency charges used as the default for all non-specified currencies.

Offsetting And Waiving Charges

On specific ACCOUNT records, charges may be calculated for information only and then waived.
Charges may also be waived if a certain average or minimum balance is maintained, if the amount of
the charge is below a value worth charging or if the account has not been into debit.
It is possible to specify that charges do not apply to foreign currency accounts.
Notional credit interest can be calculated and offset against the charges.
Limits
The LIMIT.REFERENCE field on the ACCOUNT connects the account with the LIMIT system. Limits
are checked at each on-line transaction and at end of day. The value in this field will automatically be
set to NOSTRO for that type of account or a valid LIMIT.REFERENCE relating to a product or global
limit.
For certain types of limit product it is possible to net credit account balances and debit account
balances (the usual practice is to only include debit balances for limit checking). If an account with a
credit balance is to be included in the limit checking, the field ALLOW.NETTING should be set to YES.
Account Statements
Account statements show details of all entries over the ACCOUNT since the last statement. Entries
are listed in transaction date sequence and may show both transaction date and value date.
Statements can be produced every working day, for 1-9 weeks, twice a month (on the 15th and the last
day of the month) or for 1-99 months (using any day of the month as the anniversary or on the month
end date).
Two statement cycles may be specified for each account, e.g. weekly and monthly.
These cycles may be independent or combined:
• Separate: Statements for each cycle show details of all entries since the last statement in the same
cycle, regardless of the other cycle.
• Combined: Statements are produced on the dates specified by both cycles, but only contain details of
entries since the last statement from either cycle.
If there have been no entries since the last statement, the statement may be suppressed unless six
months have elapsed.

Special interim statements, showing details of all entries since the last regular cycle 1 statement, may
be produced any day without affecting the regular statement cycles.
When a duplicate / interim statement is produced on request a charge may be applied for the issue of
the statement.
This charge is usually deferred until the next time the statement is printed in accordance with the
statement frequency. The charge may now be made immediately, together with the production of a
debit advice detailing the charge made when the duplicate statement is produced.
The field PRINT.ROUTINE on the PRINT.STATEMENT file can be used to specify the name of an
external routine written by the users that will be called to print the statement. If this field is populated
the program will call this routine and ignore the normal printing process.
Another field CHARGE.ROUTINE on the PRINT.STATEMENT file could used to specify the name of an
external routine written by the users that will be called to apply an immediate charge to the account for
which the statement is being reprinted.
The alternative method of raising the charge accounting entries would be to use the Generic
Accounting Interface.
Figure 32 - PRINT.STATEMENT
Account Violations
The AC.VIOLATION file is used to record and report violations that occur on an account within a
statement period. All transactions eligible (i.e. defined in ACCT.GROUP.CONDITION) are recorded in
this file whether or not the number of transactions equals the threshold concerned. If the number of

eligible transactions equals or exceeds the TXN.THRESHOLD for the ACCT.GROUP.CONDITION, the
AC.VIOLATION record is flagged as being in violation (i.e. VIOLATION.STATUS = Y). This file is
updated daily during the End-of-Day processing but may be also be updated manually if a transaction
needs to be added or a status changed. Transactions are held by STMT.ENTRY id. Records remain
on the AC.VIOLATION file for the length of time defined in the RETENTION.PERIOD field on the
relevant ACCT.GROUP.CONDITION.
Account violations occurring prior to the completion of a statement period will be generated in the End-
Of-Day processing and held on the AC.VIOLATION file with an id composed of the account number
alone.
On completion of the statement period, all entries on the AC.VIOLATION file held with an id of the
account number, will be amalgamated into the violation record for the statement period just passed. i.e.
that held on the AC.VIOLATION file with an id composed of both the account number and the
statement period having just passed.
Figure 33 - Account Violation

Account Sweeping
Account Sweeping is a mechanism for creating automatic payments across a number of accounts at
the COB phase based on the balance reaching a predefined ‘Trigger’ amount.
This functionality runs off two main tables, AC.ACCOUNT.LINK that defines which accounts are to be
linked together in a given sweep, and AC.SWEEP.TYPE, which defines the different styles of, sweep
available.
Sweeping happens at the End of Day during SYSTEM.END.OF.DAY2 in a job called

AC.EOD.ACCOUNT.SWEEP. The resulting movements are then stored on the live file
AC.ACCOUNT.SWEEP.HIST.
AC.SWEEP.TYPE
Sweep types can be defined with different transaction codes for the sweep or return sweep. There is
also the facility to plug in a routine for calculating the amount to sweep. If this routine were not present
then the processing would move to do a default sweep to the absolute minimum or maximum value as
set on the link record. Lastly for different sweep types you can define the direction of the sweep as
Maintenance, Surplus or Two-way.
Maintenance (Standard Sweep)
This sweep involves sweeping from the ‘from’ account to the ‘to’ account when the to account falls
below its minimum limit.
Surplus (Return Sweep)
This sweep involves the sweeping of funds from the to account to the from account when the balance
in the to account goes above the maximum value
Two way (Sweep and return sweep)
This style is simply a Maintenance sweep and a surplus sweep in one link. In this case, the
maintenance sweep always goes first.
In all cases, either the amount of the sweep is defined in the API routine or it is enough to bring the
balance back to the relevant maximum or minimum amount. The ‘from’ account can never be brought
below its minimum amount.
There is also the facility to enable the sweeping mechanism to take into account the limits of the
accounts used when calculating trigger amounts. This would mean an account with a trigger amount

of £200 and a Limit of £100 would trigger when the balance passed £100. This is achieved by setting
the USE.LIMITS field to YES
For return sweeps the funds will always go into the first account in the ACCOUNT.FROM field. However,
by setting the field PRIOROTISE.OD you can specify the sweep to clear any overdrafts amongst the
‘from’ accounts first. This would mean that if there were two from accounts with the first having a
balance of £200 and the second -£50, the sweep would place £50 in the second account and £150 in
the first.
Figure 34 Maintenance a/c sweep

Figure 35 - Maintenance Account Sweep Type
AC.ACCOUNT.LINK
Accounts will be linked through a new table. It will allow multiple to and from accounts to be linked
from across multi company environments. You would assign the SWEEP.TYPE for that link as well.
The last part of the link would be the relevant minimum/maximum amounts for the to account and the
minimum amount of the from account. The Accounts may be of any currency or customer. If an
account has a posting restriction on it then an override will be raised. Similarly you cannot close an
account that has an active AC.ACCOUNT.LINK.

Figure 36 - Setting up a Maintenance Sweep for an account
Account Sweeping History

All sweeps will be recorded in a live table called ACCOUNT.SWEEP.HIST. This table is keyed by
account and month. It will hold all the sweeps done on that account within the given month. They will
be sorted by day swept and accompanied by a unique reference of debit account–credit account–date.

Figure 37 - Historical record of Sweeps
Overview of Input and Processing

Multi-Level Cash Pooling
Multi-level cash pooling is an extension of account sweeping where numerous accounts can be
grouped together and their balances moved up to a top level account where the benefits interest
benefits can be gained on the accumulated balance.
The easiest way to envisage a ‘Group’ or ‘Cash Pool’ is that of a family tree like structure. All accounts
that would qualify for a cash pool will need to have conditions or rules that dictate when and how much
money should be transferred to another account. As mentioned above the purpose of a Cash Pool is
to be able to move funds together at a higher level, the proviso to this would be to ensure that
accounts lower down in the Group tree remain at a certain level and do not fall into overdraft.
There are currently three styles of sweep, (movement). These are maintenance, surplus and two-
way. Maintenance is when an account balance falls below a predetermined level and needs to get
funds from another account to ‘top-up’ the balance. Surplus is when an account has excess funds

(again above a certain predetermined limit) and moves the excess into another account. A two-way is
a combination of the other two; if it is below a limit then get some funds, otherwise put the excess
balance to the another. The surplus will be extended to enable different accounts to be swept into
depending on the balance on the originating account. E.g. If the balance on account A is 900m, move
700m into account B; everything between 700 – 800m goes into account C, and finally any balance
over 800m goes into account D. If account A in the example above is in overdraft then the rule will not
take effect. There is also another new rule, CASHFLOW rule; CASHFLOW, which in essence allows a
two-way rule to have a budget, assigned to it this enabling rule balance monitoring to be used. So an
account can be given an amount of 500m to use and it cannot take more than this figure in sweeps
unless it adds to it.
There is a parameter file, AC.CP.GROUP.PARAM which users will use to enter the parameters that
will control each group that the bank wish to set-up. There is no constraint on the number of pools that
can be in operation, nor is there a restriction on the number of accounts per group. Within the
parameter file the user will enter such information as the default balance to use for the pool, the
highest level account, (the ultimate target for the funds to be swept up into). There must also be
information added as to the type of sequencing to use and whether or not this is a main group or sub-
group – discussed later.
As with the account sweeping functionality there are basic conditions or rules available that will dictate
what an account does with it’s current funds. They are Maintenance, Surplus, Two-way and Cash
flow. Each rule has it’s own objective, the Maintenance rule is used to get funds from another account
if it’s balance should fall below a certain level. The Surplus rule will place funds above a certain
account balance into another account. The Two-way will be a mixture of Surplus and Maintenance; if
the balance falls below a certain level then transfer funds into this account otherwise transfer money
away to another account. The cash flow rule is more complex in that it involves two balances that the
user will initially define , the CASHFLOWDEFINE - the cash flow balance which limits the monetary
amount that can be passed down to account B from account A and the aggregate balance which will
be a running total of monies passed between the two accounts . These two balances accumulated
together set the limit on monies that can be passed down from Account A to Account B at Start of Day;
so once a year, (or whenever you choose) account A states that account B has a cash flow balance of
700million. Throughout the year, with a combination of the other three rules, the aggregate balance
between A an B is 150 million . This 150 million added to the cash flow balance of 700 million
indicates that Account B may receive up to 850 million swept down from Account A. (E.g. there may
have been a large dividend paid into a lower level account which has swept up into this higher level
account). Until the aggregate balance changes the cash flow balance will now be 850million for this
account. It is possible that an account lower down in the pool has had a major mishap and needs to
top-up an overdraft by 200million thus reducing the amount that account B has in it’s aggregate
balance to -50million DR. In such case the balance now available to Account B is 700 million + 50
million DR = 650 million and this will be the maximum amount that can be used until once again it
changes.
Once the parameter file is set the pool is ready to be set. Every account that is to be part of the pool
will need to have information added to the new file AC.CASH.POOL, this is where users will enter
information unique to this account and detail how this account is to interact with the larger pool as a
whole. It will be in the AC.CASH.POOL file that the rule type, (one of Maintenance, Surplus etc) will be
entered. Also entered, also the sequence number of this account within the pool. If a sequence of 34
is entered here then this account would be processed after account 35 and before account 33. It is
possible to change these sequence numbers at any time while an account is still part of a pool by pool.
By entering 72.1 it would inform the system that this account is to be inserted into the tree-like
structure after number 72 and before number 73. So the account with the 72.1 entered in the
sequence field will become number 73 and number 73 will become number 74. This file will also be
used to enter the frequency of each rule entered for an account. This facility gives banks complete

control over their cash pools, how they run, when they run and how much each account will contribute
to the cash pool.

AC.CP.GROUP.PARAM
In order to start to use the Multi-level Cash Pooling functionality the first thing to do is to define a group
on the parameter file that contains basic controlling information. A simple parameter record would look
like this:
Figure 38 - AC.CP.GROUP.PARAM record
From the example it can be seen that a group can be defined as either a main group or a sub group,
the only restriction being that a sub group must be of the same currency as it’s main counterpart. Also,
in the example above, this sub-group is to be used for Cash Pooling only. The field
SHARED.BALANCES indicated indicates whether a group is for Shared Balances or just Cash Pooling.
Using the Cash pool application, surplus funds in the Cash pool account can be moved to a
MONEY.MARKET Contract by specifying the MAIN.MASTER, MAIN.DEPOSIT, OFS.SOURCE and
MM.OFS.VERSION in AC.CP.GROUP.PARAM. Money market Contract related information
INTEREST.KEY or INTEREST.RATE or INTEREST.SPREAD, CATEGORY, and INT.LIQD.ACCT
could be given in AC.CASH.POOL. Using the above information, MONEY.MARKET contracts will be
created during End of day Close of Business processing and will be matured in the immediate
beginning of day and Principal along with the Interest will be credited as per Cash pool set-up.

AC.SWEEP.TYPE
Released into T24 are a couple of basic rules, which are needed as a minimum system requirement,
SURPLUS, MAINTENANCE etc. These can be added to or amended to tailor them for the bank’s
specific needs. They are entered into the file AC.SWEEP.TYPE. We can see below that the
SWEEP.STYLE has been set to surplus, surplus which means that funds will be placed into another
account depending on the conditions entered into the AC.CASH.POOL file. As you can see the
BALANCE.TO.USE field is blank.. In this case the mandatory field in the parameter file will be used.
Figure 40 - AC.SWEEP.TYPE

AC.CASH.POOL
Once the Parameter file has been set up, the group is effectively ‘Live’, so now is time to assign an
account to a group. As you can see below this is a SUPLUS rule to run daily and above 10,000,000.
So this rule states that; every business day (FREQUENCY) take any amount over 10,000,000
(MAXIMUM.AMT) from account 16446 (the record ID) up to an amount of 500,000 and put it into
account 16478 (LINK.ACCT). The field GROUP.ID indicates that this account (16446) is in the Multi-
level Cash Pool Group called “COUNCIL” which is a sub group of the Multi Level Cash Pool Group
called “HOUSING”. The bank may want to use more descriptive names, names this would be totally
controlled by them.
Table 1 - AC.CASH.POOL

Once the cash pool record is authorised then it becomes part of the pyramid sweep and thus is
included in the overnight sweeping processes , the frequency deciding when amounts are swept.
The amount to be swept depends on how the cash pool record is set up. For a surplus sweep the
MAXIMUM.AMT field becomes mandatory. This is the maximum amount that can be held in the
balance specified for the keyed cash pool record. This is what will trigger the sweep. If the balance is
above the maximum amount then the sweep amount can be decided in the following order:
The OVERRIDE.AMT field.

The OVERRIDE.PERCNT field.
The AMT.ROUTINE API slot on the cash pool record.
The AMT.SWEEP.ROUTINE API slot on the SWEEP.TYPE record.
The difference between the maximum amount and the specified balance amount.
No matter what sweep amount is processed from the above , if it is greater than an amount entered in
the UP.TO.AMOUNT field then only the value in this field will be swept.
We can specify the amount in MIN.TFR.DR and MIN.TRF.CR, to restrict creation of sweeping
entries for a smaller amount.
RTN.WITH.SW.AMT – an interface to user routines
When RTN.WITH.SW.AMT field is set after attaching a local routine in the field AMT.ROUTINE in
case of AC.CASH.POOL or in the field AMT.SWEEP.ROUTINE in case of AC.SWEEP.TYPE, the
routine will be called after the sweep amount is calculated by the system, before all updates to sweep
history and other files are made.
The routine will have the following five parameters:

1. Account balance of TO account before sweep amount is calculated, along with TO account ID
2. Account balance of FROM account before sweep amount is calculated, along with FROM
account ID
3. Sweep amount with appropriate sign
4. Cash pool link record and
5. Value Date of sweep transaction
The third parameter, sweep amount will be used by the called routine for further validation as per
client’s local requirements and will be passed back to the system for raising the sweep transaction.
If both AC.CASH.POOL and AC.SWEEP.TYPE have routines specified, then the routine in
AC.CASH.POOL will take precedence.

INFORMATION SWEEPING
There is an on line application – INFO.SWEEP.CP keyed by cash pool group which will display any
pending cash sweeps for that day and the resulting account balances for a specified group. No
updates are performed by this application. It is purely for informative purposes and can be run many
times a day.
ON-LINE SWEEPING
There is the facility within cash pooling to run a group or sub group on line as many times per day as
required. A group may be defined to run only once or multiple times per day via it’s group parameter
record. The flag INTRA.DAY may be either SINGLE or MULTI. Single meaning a sweep of this group
can only occur once per day, which may be on line or during the overnight batch processing . Multiple
means that a group may be swept many times a day as well as during the overnight batch process. A
record of all accounts swept is held in the AC.ACCOUNT.SWEEP.HIST application.
In the above AC.CP.GROUP.PARAM example the group COUNCIL may be run many times per day.
It is however a sub group , part of the main group HOUSING. The main group may be single or
multiple. If the main group was single and run once , it would still be possible to keep processing
COUNCIL as many times as was required. If however HOUSING was multiple and COUNCIL was
single then no matter how many times HOUSING was processed , the links within COUNCIL would
only have been swept the once.
There is a further option in the cash pool record that allows the user to specify where this pool record
may be processed.. The SCHEDULE field may contain either INTRA, EODCOB or blank. If INTRA then
this pool record may only be included in the sweep via on line processing. If it was due to be
processed today but no online processing was performed, then during the end of day ,Close of
Business the frequency dates would be recycled but no funds would be swept.
If SCHEDULE contains COB then this pool will only be processed during the Close of Business. If left
blank then the pool record may be processed both on line and during the end of day. Close of
Business.
INTRA DAY SWEEP

INTRA.DAY.SWEEP application is used to run sweeps during the day. Sweep can be triggered
manually by invoking “V” function for each group in INTRA.DAY.SWEEP. To trigger automatically the
sweeping processing, the required schedule time for cash pool group can be specified in
INTRA.DAY.SWEEP and once the EB.PHANTOM application is invoked with RUN.ROUTINE as
“AC.AUTO.SWEEP.SELECT”, all the cash pool records scheduled for today under the group is
executed automatically.
END OF DAY SWEEPING
End of Day Sweeping

A link will be included in Close of Business when its frequency date is less then or equal to the
processing date and one of the following applies :

1. The SCHEDULE field on it’s corresponding group parameter record is either blank or EOD’COB.
2. The INTRA.DAY field on the parameter is either MULTI or SINGLE and with no online processing
taken place
SWEEP REVERSALS
The REV.GROUP.CP application allows you to reverse and Close of Business cash pool sweep. Enter
the group name with the ‘V’ function and all accounts swept during the previous Close of Business run
will be reversed. This application does not work with intra day sweeping..
SWEEP RERUNS
Sweep Reruns
The RERUN.CP.SWEEP application allows you to rerun a sweep only after it has been reversed. It
allows the user to enter any back value transactions that may have been omitted from the previous
sweep and these transactions will be included in the new sweep. The sweep can only be rerun once.
Any transactions entered before the rerun with a value date of today will not be included in the sweep
as it is a rerun of the last working day’s sweep only.
SWEEP PRIORITIES
Sweep Priorities
During cash pool processing, either Close of Business or on line all cash pool records with a
frequency date less that or equal to the processing date will be swept.. As there can be many links on
one cash pool record you may get the scenario where two links are to be processed on the same day,
e.g. a link to run daily will eventually coincide with a weekly link.. This obviously would make no sense
and so functionality exists to assign each link a priority to dictate which link is to be processed. A
RULE.PRIORITY field exists on the group parameter record and it’s valid values are ‘FREQUENCY’
and ‘PRIORITY’.
The FREQUENCY option means that during Close of Business when a link date is to be cycled , if a
link already exits with the cycled date then the date will continue to cycle until a unique date is found.
This therefore eliminates the possibility of two links running together.
The PRIORITY option allows the user to assign priorities to each individual link so should it occur that
there are more than one link to process, then the link with the highest priority wins (1 being the
highest). When entering a pool, if its corresponding parameter record is set to use priorities then the
user is forced to prioritise each link in the pool.
SHARED BALANCES
Shared Balances
Shared Balance processing is an extension of Multi-level Cash Pooling where accounts which are
grouped together, as described above, have their combined balances (Balance + overdraft) checked
when a transaction is passed across one of the accounts in the group. If the transaction is larger than
the accounts balance and would normally put the account into overdraft then the usual overdraft
processing that T24 performs will be extended to consider all the other accounts balances in the group.

If an account is to be part of Shared Balance checking then first a parameter record must be set, first
(as described above) with the SHARED.BALANCE field set to YES. Now all accounts entered onto the
AC.CASH.POOL file for this group will be considered for cash pooling. If an account is for shared
balance checking then on the AC.CASH.POOL file it will have the frequency set to daily and the
amount set to 100% of the balance. This is to ensure that during the end-of-day routines all the money
that was checked will be moved as expected.
If an account is for Shared Balances then there can be no other Cash Pooling against it and there can
be no online movement of funds except during the Close of Business. The one proviso to this is that a
sub group could pass funds into a shared balance group which it is not part of.
BACK VALUED CASH FLOW TYPE OF CASH POOLING
If the option has been set in the AC.CP.GROUP.PARAM to allow adjustments to sweeps already
performed, then when a back-valued entry is passed across one of the monitored accounts the system
will create an adjustment. The adjustment could be a new sweep, the cancellation of a sweep, or an
adjustment to increase or decrease the amount that swept.
If the result of these adjustments affects another monitored sweep account then that account will also
be checked to see if any adjustments are required.
The adjustments are value-dated meaning that each value date from the back value to the current
date is assessed for any impact on the sweeps performed.
Ideally any back-value should be processed but given the complex and varying scenarios it would be
impractical to expect any system to re-calculate cash pool sweeps for more than a few days, a limit of
31 days has been set. This value van be reduced by setting field BACK.VALUE.CAP on the
AC.CP.GROUP.PARAM record.
Example
In this example we will sweep the funds in Account 40568 to 40576 and keep the balance at zero. The
only time a sweep may not be needed is if the amount to sweep is less than $10.00, as these would
be considered too small to merit the operating costs or any transactional charges the bank may
impose.

Account before first sweep

The account is primed with a credit of $25,000.00 value 9th September 2005. Our expectation is that
this will be swept up to the link account tonight.

Account after COB
Here we can see that the $25,000 has been swept out of the account, note the value date of the
sweep is the same as the credit date.
Account after new postings
The entry, which was missed on the 9th Sep 2005, was a debit for $5,000 has now been posted. This
means that the sweep that took place was for too much and needs correcting

Account after next COB
To correct the over sweep from the previous day an adjustment sweep has now been posted for
$5,000. The value date is set to the 9th Sep 2005 so from an interest calculation viewpoint the account
has a zero balance, the debit of $5,000 will not cause an overdraft since it is compensated by the
adjustment.
A file CORR.GROUP.CP records details of all back value processing. It is keyed on the account
number to be back back-valued, the value date of the back value transaction and a sequence number.
(it(It is possible that an account may receive more than one back value transaction.) Each record will
hold the details of all accounts re swept as a result of the original accounts new balance.
As many accounts may be affected, the key to CORR.GROUP.CP is help in the account sweep
history record of every account included in the back value process.

Figure 43 - Back Value Correction Record
BACK VALUED ADJUSTMENT-NON CASH FLOW SWEEP TYPE

Discretionary and Non- Discretionary are the two types of back value adjustment set-up in Cash pool,
which is explained below.

Back value dated Adjustment in Discretionary Accounts
A discretionary relationship is where the accounts are managed by the bank and are not subject to
restrictions such as maximum number of debits. This cash pool set-up is similar to the normal cash
pool.
To effect adjustment entries, when there is are back value dated entries in Cash pool accounts, in
AC.CP.GROUP.PARAM, the BALANCE.TO.USE should be VALUE.DATED with BACK.VALUE.ADJ
set as “Yes”. The AC.CASH.POOL can be created like a normal cash pooling record with the ID and
link account along with the sweep condition.
The start date for back value processing is arrived at from the latest among the following:
• Cap Back value date arrived using BACK.VALUE.CAP from AC.CP.GROUP.PARAM .
• LAST.MAINT.DATE, which is available in AC.CASH.POOL.
• Actual oldest back value transaction date.
For example:
• Cash pool record got created on 05th Jun, then the LAST.MAINT.DATE is 05th Jun .
• BACK.VALUE.CAP is mentioned as 10 days in AC.CP.GROUP.PARAM.
• On 8th Jun back value-dated transaction done with value date as 01st Jun.

Then start date for back value adjustment starts from the latest of the above, i.e. 05th Jun and the back
value adjustment entry will be passed from 5th Jun even though the actual back value dated is 01st Jun.
If any change is done to an existing AC.CASH.POOL record, then the LAST.MAINT.DATE will be
updated with current system date and old links details will be ignored for back value date adjustment
processing.
Example for Back value dated adjustment for Discretionary Accounts
For Account 123456 Cash pool condition record created to sweep any amount above USD10000 with
frequency as Daily. The Cash pool group has the BACKVALU.ADJ Flag is set to YES.
Following are the sweep history details.
Following are the sweep history details.
DATE BALANCE (USD) SWEEP AMOUNT (USD)

01 JAN 20000 10000
02 JAN 17000 7000
03 JAN 7000 0 (Less than 10000)
On 4-Jan the following back value dated transaction are done:
Dr 123456 Value dated 01-Jan-2002 USD 5000.00

Cr 123456 Value dated 01-Jan-2002 USD 20000.00
Dr 123456 Value dated 02-Jan-2002 USD 5000.00
Cr 123456 Value dated 03-Jan-2002 USD 4000.00
Based on the revised account Balance, the following entries will be passed for Account 123456 with
the respective value date.
VALUE OLD NEW OLD NEW SWEEP ADJUSTMENT

DATE BALANCE BALANCE SWEEP AMT ENTRY
AMT
01 JAN 20000 35000 10000 25000 -15000
02 JAN 17000 12000 7000 2000 5000

03 JAN 7000 11000 0 1000 -1000
Back value dated transaction in Non-Discretionary Accounts
Non-discretionary type of accounts is where there are local requirements governing how many entries
can be passed each month over the client’s account.
Following are the requirements of a Bank for Non-Discretionary accounts.
Bank has two type of accounts i.e. DDA &The Bank has two types of accounts, i.e. DDA and MMDA.
The surplus in the DDA account is transferred to MMDA and any short fall in DDA, the DDA balance
will be transferred from MMDA. There is a restriction on debit entries to the MMDA account of say only
5 entries per month and no such restriction on DDA accounts.
For the above requirement, set the MULTI.RULE as “YES” along with the balance to use as
VALUE.DATED and BACK.VALUE.ADJ as “Yes” AC.CP.GROUP.PARAM.
In AC.CASH.POOL, give the DDA account as an ID account and set up the MMDA account as a link
account with the sweep type as Surplus and frequency as “Daily”. Based on the restriction on the
number of entries, set the appropriate frequency. In this case the number of entries are restricted to 5
–5, hence the frequency is given as “WEEKLY”.
“WEEKLY”
Surplus sweep will happen daily and if there is any back value dated entries to the DDA account,
which will result in a Surplus sweep, adjustment entries will be passed along with the normal sweep
amount.
Because of the restriction on debits to MMDA, any shortfall in DDA will be passed as a consolidated
entry by posting the highest shortfall amount with the value date as the first shortfall date for a given
frequency in this case weekly.
When both sweep type frequencies fall on the day, then maintenance will be executed first by posting
the highest short fall amount with value date as the first short fall date- if any exists, or from the last
maintenance frequency run date, followed by the surplus sweep from the date next to the highest
short fall date
Example for Back value dated adjustment for Non-Discretionary Accounts
After all postings up to yesterday have been included in the work files the balance of our example
DDA looks as follows:

Balance Requirement USD 5,000

System Date 14th July 2000
DATE BALANCE SHORTFALL

July 10th (11,000) (16,000)
th
July 11 (23,000) (28,000)
July 12th (8,000) (13,000)
th
July 13 (8,000) (13,000)
July 14th (8,000) (13,000)
Our work file will have selected the oldest date as July 10th as this is the earliest date where there is a
shortfall. The largest shortfall occurs on July 11th so we need to credit the DDA account with USD
28,000 to leave a balance of USD 5,000.
In order to limit the number of correcting entries to pass, this credit will be posted with a value date of
the earliest shortfall. If we were checking the balances of the account for each date before the daily
sweep job was run this would give a theoretical balance picture as below:
DATE BALANCE SHORTFALL ADJ BY TEMP BAL

th
July 10 (11,000) (16,000) 28,000 17,000
July 11th (23,000) (28,000) 28,000 5,000
th
July 12 (8,000) (13,000) 28,000 20,000
July 13th (8,000) (13,000) 28,000 20,000
th
July 14 (8,000) (13,000) 28,000 20,000
During month end, maintenance sweep will run irrespective of whether maintenance frequency is
there or not
.
Any debit reversal to the surplus amount which is already swept will not be allowed as it will break the
number of debit transactions to MMDA. However the details of the transaction will be written in the
Exception log file with the amount to be reversed along with the AC.CASH.POOL id.
Back value Adjustment details

The regular and back value dated sweep details will be available along with the Debit and credit
account balance of Sweep related accounts in AC.ACCOUNT.SWEEP.HIST.

Figure 45 - AC.ACCOUNT.SWEEP.HIST – Adjustment details
Also gives us the original balance &and original sweep amount and account balance after back value
dated adjustments &adjustments, and revised sweep amounts along with the date and adjustment
amount entry, which is passed.

The field LAST.MAINT.DATE on AC.CASH.POOL controls how far back any adjustments can be
made to. Any entry earlier than that date will be processed as if it equals that date.
This date may be modified if the underlying rules have been modified and the date will be reset to the
date the changes are made.
Payment Netting
Overview
The payment netting facility provides the ability to automatically net payments with a counter party in
the same currency and with the same value date. Netting is permitted only when a
NETTING.AGREEMENT is held with the counter party. The netting agreement has a finite life and
indicates which currencies may be netted with this counter party.
Net payments must be agreed and approved before the payment is generated. This is done using the
NETTING application. T24 will automatically consolidate payments eligible for netting into a ‘netting
group’, which will appear as a single record on the NETTING application. This record may then be
reviewed and confirmed with the counter party. Authorisation of the NETTING record will generate the
single netted payment.
During the review of the NETTING record, individual payments may be rejected for inclusion in this net
payment. Any payments thus rejected will remain in suspense and will automatically be included in the
next netting group created for the same currency, customer and value date. Once a payment has
been selected for netting it can only be made using the NETTING application.
Netting groups may be created during the T24 overnight processing (based upon forward deals) or on-
line (using the CREATE.NETTING application) for spot deals.
The accounting entries for payments that are to be passed across a suspense account, which should
have a zero balance once all net payments have been sent.
Individual payments that are to be net are recorded on the NETTING.ENTRY application. This is a
‘live’ file; i.e. it is not available for input. There is one NETTING.ENTRY record for each contract.

Figure 47 - Netting file structure

Accounting for net payments
Payments that are netted pass across a suspense account. For example if we are paying US dollars
to a counterparty with a value date of spot, and are expecting one receipt of US dollars funds from the
same counter party with the same value date then if we are not netting payments, T24 will generate
the following entries:
Figure 49 Standard accounting entries
If the payments were netted then T24 would generate the following:
Figure 51 Accounting entries with payment netting
All entries in the above examples are STMT.ENTRY records.
Installing the payment netting function
The following steps need to be followed:
1. Open new TRANSACTION codes for netting entries.

2. Open a new CATEGORY code for netting suspense accounts.
3. Open an ACCOUNT.CLASS record for NETTING.
4. Open the netting suspense accounts (only one is mandatory).

5. Input the NETTING.PARAMETERS record.

6. Set the ACCOUNT.PARAMETER to allow netting.

Setting up the payment netting suspense accounts
The payment netting facility requires suspense accounts. Setting up these accounts is done in two
stages: an ACCOUNT.CLASS record is created and then a suspense account is opened which will act
as a template for all the suspense accounts.
The ACCOUNT.CLASS record to be established has a key of NETTING. This record is used by T24 to
determine the characteristics of the suspense accounts to be set up to hold the netted payments.
Before setting up the record a new CATEGORY code should be created for netting suspense
accounts. This code will be referenced by the ACCOUNT.CLASS parameter.
Figure 53 - Netting ACCOUNT.CLASS record
Once this is complete the internal netting suspense accounts may be opened using the ACCOUNT
application. The id of these accounts is the same as any other internal account, i.e. the CURRENCY,
CATEGORY, and a four-digit identifier. E.g. USD149550001.

Figure 55 - Netting Suspense Account

Setting ACCOUNT.PARAMETER for payment netting
The ACCOUNT.PARAMETER contains a field (NETT.PAYMENTS), which must be set to YES for
payment netting to take place.
Use of the NETTING.STATUS field on contracts
All contracts whose payments may be netted contain a field called NETTING.STATUS. This field may
be used at contract input time to stop the payments arising from this contract being netted.
The NETTING.ENTRY application
The NETTING.ENTRY application contains details of all entries being netted. Records are created
here upon authorisation of the original contract. When an individual payment has been successfully
included in a net payment then its entry on this file is updated.
The NETTING application
The NETTING application is the main control over the net payments process. All individual payments
selected for netting are combined into a single netting record for the counter party, currency, and value
date combination. This record may then be reviewed and amended if necessary. Once the net
payment is correct the netting record is authorised and T24 will create the single net payment or
receipt accounting and delivery messages.
Individual payments may be dropped from a net payment at this point. If dropped they will remain in
suspense until captured in another net payment. Therefore once a payment has been selected for
netting, it can only be paid using the NETTING application. Individual payments may, of course, be
removed from netting by reversing and re-inputting the source contract and ensuring that the
NETTING.STATUS field is set to NO on the re-input.

Parameter Files
ACCOUNT.PARAMETER- Controls Account & Defaults

The ACCOUNT.PARAMETER record contains high-level specifications for the ACCOUNT application.
For example:
• Number of days forward for cash-flow processing.

• Whether accounting is performed on a value date or booking date basis.
• Whether accounts can be referenced by an alternative id or not.
• Whether the customer number must form part of the account number.
• Whether payments can be netted.
• How settlement defaulting is to take place.
There is only one record, with an ID of SYSTEM.

Figure 57 - ACCOUNT.PARAMETER
The field SYS.CODE in ACCOUNT.PARAMETER holds the combination of application-activity or

“ALL” based on which the settlement accounts such as Drawdown, Liquidation etc are defaulted in
Applications such as LD, MM etc. In the application AC.SYS.CODES, the above application-activity
combinations can be defined along with the relevant description. The required SYS.CODE in
ACCOUNT.PARAMETER can be selected through the linked application AC.SYS.CODES and
enrichment as given in AC.SYS.CODES will appear here.
Example. LD-INT, which refers to the interest liquidation account in the LD application, can have a
record in AC.SYS.CODES as follows:

Figure 59- AC.SYS.CODES with description
CUSTOMER.SSI is an application which is used to define the Standard settlement instruction (SSI) for
a particular customer which is then used to default settlement account fields such as DRAWDOWN
ACCOUNT, PRINCIPAL LIQUIDATION ACCOUNT & INTEREST LIQUIDATION ACCOUNT,
in applications such as LD, MM, FX, MG, NETTING, BL.BILL, PD.CAPTURE &
PRE.SYNDICATION.FILE. A new field CUSTOMER.SSI has been added in
ACCOUNT.PARAMETER to control the above feature.
Figure 60- Customer.SSI field in ACCOUNT.PARAMETER
If this field is set to “YES” (along with DEFAULT.ORDER field of the required SYS-CODE field as
blank) then during input of contracts for the above applications, the system first checks for a matching
record (combination of CUSTOMER, CURRENCY, SYSCODE or “ALL”) in CUSTOMER.SSI to
default in the relevant settlement Account fields. During capture of a contract the SSIs defined have
the highest priority for defaulting.
In case the Counter party does not have a record for the above combination in CUSTOMER.SSI, then
overrides are generated at the application level and the settlement accounts are defaulted as per
existing functionality of the respective application.
In case the CUSTOMER.SSI field in ACCOUNT.PARAMETER is set as ‘blank’, then the system will
not allow input in CUSTOMER.SSI application and uses the existing functionality of the respective
application for defaulting settlement accounts.
Example: Create the following record in CUSTOMER.SSI application for customer no. 1044 (Michael
Dell):

Figure 61 - CUSTOMER.SSI Set-up for a Customer
While inputting a LD contract in USD for the above customer, the settlement accounts get defaulted as
shown below using above set-up:
Figure 62 - Defaulted settlement accounts in LD
Suppression of unnecessary overrides
If a single contract will create both credits and debits to an account, if the net effect of the contract is to
credit the account, it is possible to suppress the override generated for the debit side of the transaction.
For example, if a discounted loan is arranged for a client, whereby the customer has a balance of £10,
receives a credit of $1000 for the loan, but also a debit of $100 for the upfront payment of interest.
The system would usually generate an override specifying that as the customer is being debited $100,
the client is overdrawn by $90. However, it is possible through the fields NET.OD.APPL,
NET.OD.OVERRIDE on ACCOUNT.PARAMETER to net off the differences so as the credit of $1000
exceeds the debit of $100, the override can be suppressed.
The applications for which this functionality is needed is entered into the NET.OD.APPL field and it
can be switched on or off by setting NET.OD.OVERRIDE as ‘YES’ or ‘NO’. Currently this functionality
is allowed only for LD – LOANS.AND.DEPOSITS.

ALT.ACCT.PARAMETER - Alternative Account numbers
Specifies the structure of an alternative ACCOUNT number.
Figure 63 - Alternate Account Parameter
In practise where T24 has replaced an existing system it may be a short-term requirement to allow the
access to client accounts using the old account numbers. In order to allow this, a special parameter
file, ALT.ACCT.PARAMETER needs to be set-up. This tells T24 how the other system account
number structure was defined.
Once this is set up it is possible to enter the old account number on the ACCOUNT record in the field
ALT.ACCT.ID.
An index is kept in ALTERNATE.ACCOUNT, the id is the external system account number and the
single field GLOBUS.ACCT.NUMBER contains the T24 equivalent.

Extending ACCOUNT type fields to enable IBAN and other account numbers
The standard maximum length of ACCOUNT type fields is 16. However, due to requirements to enter
extended account numbers, such as IBAN numbers, it is possible to extend this maximum limit
through the EB.OBJECT application.
Workflow to extend capacity of the ACCOUNT field is as follows :
Figure 65 Defining Account number length on EB.OBJECT
On the ACCOUNT record for EB.OBJECT, the maximum length of input to an account type field is
specified. In the above example, it would then be possible to type up to 36 characters into account
type fields.
Then, in the application ALT.ACCT.PARAMETER, alternative account formats can be specified–

where a maximum length of fields may be up to the number specified in EB.OBJECT.
Figure 67 - IBAN alternate account numbering
In CHECKDIDGIT.TYPE, a routine may be entered to validate the ALT.ACCT.ID entered.

Of course, multiple ALT.ACCT.PARAMETER records may be created, to allow various different

alternative account numbers.
POSTING.RESTRICT - Posting restrictions
This file contains various types of restrictions that may be defined, such as ‘Post No Debits’,
‘Whereabouts Unknown’.
The system will automatically close any ACCOUNT that has a posting restriction in the90-99 range of
90-99 as soon as all balances are zero. Posting restrictions in the range 80-89 are used for accounts,
which are pending closure.
Where an ACCOUNT has a value in the field POSTING.RESTRICT and attempts are made to pass
entries to it, an override message will be issued.
Figure 69 - Posting restriction types

REFERAL -– Referral
A referral is the reporting of an ACCOUNT movement or balance to an account officer

(DEPT.ACCT.OFFICER) when certain conditions are met. For example an account may be referred
when it exceeds a particular debit value, or when certain types of transaction are passed across the
account etc.
A referral is only the reporting of the account to the account officer by means of an overnight report. A
posting restriction (a stronger form of referral) should be used if an override message at input is
required.
The REFERAL table contains the pre-defined referral conditions. These are then loaded onto the
ACCOUNT record in the REFERAL.CODE field. Multiple referral codes may be specified on an
account.
Figure 71 - Referral record

ACCOUNT.CLASS - Defining internal and other accounts
This table file has two main types, ACCOUNT and CLASS.
ACCOUNT.CLASS records with a RECORD.TYPE of ACCOUNT provide the CATEGORY code

portion when building an internal ACCOUNT number (such as netting suspense account).
The use of CLASS as the RECORD.TYPE is used to identify a group of ACCOUNT records (e.g. under
a heading like NOSTRO) by matching the account details against those held in the ACCOUNT.CLASS
record.
Figure 73 - ACCOUNT.CLASS for Nostro Accounts
When the RECORD.TYPE is ACCOUNT then the CATEGORY code must be valid and in the range
10000 to 19999.

Figure 75 - ACCOUNT.CLASS for Suspense
When the RECORD.TYPE is CLASS the CATEGORY and SECTOR code fields are treated as multi
value associated fields. Either field may be null, but not both at the same time. Duplications of
CATEGORY and SECTOR code combined are not allowed within one entry on the ACCOUNT.CLASS
table.
The following records are among those permitted:
Figure 77 ‘CLASS’ ACCOUNT.CLASS records

For accounts the following ids are valid.
Figure 79 - 'ACCOUNT' ACCOUNT.CLASS records


AC.STMT.PARAMETER - Defaults for account statements
The purpose of this table is to define defaults for ACCOUNT statement details when opening new
ACCOUNT records.
This table determines whether the default ACCOUNT.STATEMENT record is set to produce
statements when there has been no movement, descriptive statements, interest and charges
statements and advices and tax advices and the minimum number of months for a statement to be
produced if at all. If no record exists the default will be 'NO' and the minimum frequency will be 6
months.
These settings can of course be overridden on the ACCOUNT.STATEMENT record itself.
Figure 81

Figure 82 - AC.STMT.PARAMETER

STMT.GEN.CONDITION - Defaults for statement frequencies
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. The default
frequency is determined by the STMT.GEN.CONDITION table.
Figure 84 – STMT.GEN.CONDITION

ACCOUNT.STATEMENT - Statement details for an individual account
When a new account is opened, an ACCOUNT.STATEMENT record is automatically generated by

the system. This specifies the date and frequency for printing statements, whether statements are to
be printed if there have been no movements and various other statement production options. Defaults
are taken from other parameter tables such as the STMT.GEN.CONDITION and
AC.STMT.PARAMETER but these can of course be overridden by input to this table.
Account statements may be produced periodically as specified by frequencies in the

ACCOUNT.STATEMENT application or on-line on an ad-hoc basis. The following SWIFT message
types are available:
• MT940 – Customer Statement

• MT941 – Balance Report
• MT942 – Ad-hoc statement
• MT950 – Statement
• Message Type MT942
Non Printing of Internal Account Statements
ACCOUNT.STATEMENT is an application, which allows the printing of account statements for all
Accounts.
The 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.
Figure 86 - ACCOUNT.STATEMENT record for Internal Accounts

Figure 88 - ACCOUNT.STATEMENT record for Customer Accounts
If the field PRINT.STMT is set to Null or Yes, the statement will be printed as normal. If however this
field is set to No, the printing of the account statement is bypassed (i.e. this indicates that the
statement will not be physically printed out but all associated tables will be updated normally, as if the
statement was printed).
The key to the table is an ACCOUNT number.
Figure 90 - Statement settings for an account


SWIFT MT492
The ACCOUNT.STATEMENT application also allows for the production of a SWIFT MT942 messages.
Three fields on the ACCOUNT.STATEMENT record control MT942’s:
SEND.MT942 Must be ‘Y’ or ‘N’

MESSAGE.TIME A multi valued field containing all the times during the day that the Message
is to be produced.
FLOOR.LIMIT The minimum value of a transaction that is to appear on the statement. Any
transactions below this amount will be included on the statement.
Figure 92 SendingMT942
Figure 94 - Sending MT942
These message types can also be produced on an ad-hoc basis as detailed in the next section.

Ad-hoc Interim transaction (MT942) reports
A customer may authorise another financial institution to receive statements and transaction reports of
his accounts. There is a facility to produce Interim Transaction Reports (SWIFT MT942) on-line on an
ad-hoc basis. Requests are entered through the application DE.MT942.REQUEST where T24 will
produce an Interim Transaction Report on the account specified. Note the 'V' function is required to
invoke the message creation.
Figure 95 Requesting a MT942
ACCT.GROUP.CONDITION - Rules for accounts
Figure 97

Figure 98 Account group parameters
The record id for this parameter file is the condition group and the currency of the account(s). Rules on
deposits, withdrawals and premium interest applying to accounts belonging to condition group and
defined for specific currency are entered here.
Further the record id for the parameter file may be suffixed with a date in the YYYYMMDD format. This
date specifies that the record is a change request for the condition group &and currency combination
specified in the first part of the key. The request records are processed in the Close of Business
processing and the new values of the parameters are passed into the active record using the values
from this request record.
It is recommended that the copy function be used to create the request record from the active record
prior to changing any parameters.

Additionally, where the requirement exists to record and report transaction violations on an account or
accounts within a particular group, this may be achieved by defining the threshold permissible before
the violation occurs and the transactions eligible to trigger a violation. The following example
demonstrates how this may be achieved.
Figure 100 Transaction restrictions
In the example above, for ACCOUNT.GROUP 1, the number of transactions, with a transaction code
of 2, 84 or 85, permissible within a statement period, may collectively add up to, but not exceed, 5
transactions. If this threshold (TXN.THRESHOLD) is exceeded, the account is in violation and this will
be recorded on the account violations file (AC.VIOLATION). The above example is set up to record
violations if more than 5 cash withdrawals or more than 3 cheque withdrawals occur within the
statement period defined for the account group into which this account falls.
The RETENTION.PERIOD field defines how long records remain on the AC.VIOLATION file before
being transferred to the history file, AC.VIOLATION.HIST. Additionally, this field also determines when
transactions are deleted from the history file. They will be deleted after twice the period defined. For
example, if '12M' is entered in this field, a violation record will remain on the AC.VIOLATION file for 12
months, it will then be transferred to the AC.VIOLATION.HIST file. The record would then remain on
the AC.VIOLATION.HIST file for a further 24 months before being deleted.
In the example above, for ACCOUNT.GROUP 1, the number of transactions, with a transaction code
of 2, 84 or 85, permissible within a statement period, may collectively add up to, but not exceed, 5
transactions. If this threshold (TXN.THRESHOLD) is exceeded, the account is in violation and this will
be recorded on the account violations file (AC.VIOLATION). The above example is set up to record

violations if more than 5 cash withdrawals or more than 3 cheque withdrawals occur within the
statement period defined for the account group into which this account falls.
The RETENTION.PERIOD field defines how long records remain on the AC.VIOLATION file before
being transferred to the history file, AC.VIOLATION.HIST. Additionally, this field also determines when
transactions are deleted from the history file. They will be deleted after twice the period defined. For
example, if '12M' is entered in this field, a violation record will remain on the AC.VIOLATION file for 12
months, it will then be transferred to the AC.VIOLATION.HIST file. The record would then remain on
the AC.VIOLATION.HIST file for a further 24 months before being deleted.
If a single limit default field in ACCT.GROUP.CONDITION is set to 'Y', then for all new account
opened, under the group single limit field in account is defaulted with 'Y'.
SAVINGS.PREMIUM - Parameters for premium types
Figure 102 Savings Premium

Figure 103 SAVINGS.PREMIUM

An option of premium interest on accounts has been provided for in T24. The actual parameters used
in the calculation &and processing of premium interest on the accounts is specified on this application.
The premium types defined here are linked to the account via the ACCT.GROUP.CONDITION record.
The INTEREST.BASIS field in this table may not be set to the ‘C2’ interest basis.
PREMIUM.DETAILS - Details of premiums paid on account
An account that capitalises premium interest will create details of the movements that were used in the
calculation process. This file details all such movements with information on the value date, amount,
date from which premium was paid, date to which premium was paid, number of days for which
premium was paid, unrounded premium amount and the rounded premium amount.
Figure 105 PREMIUM.DETAILS

NOTICE.WITHDRAWAL - Notices given on notice accounts
Some types of accounts can be set up to have notice withdrawal conditions. In such a situation for a
withdrawal to be effected on the account a notice must have been given that satisfies the notice
conditions set up on the ACCT.GROUP.CONDITION application. These notices are given through
this application.
Figure 108 Withdrawal Notice Parameters

NOSTRO.ACCOUNT - Nostro accounts
Figure 109 Default Nostro Accounts
Default NOSTRO accounts for currency and application are entered in the file NOSTRO.ACCOUNT.
Defaults can be set for each application, even for transaction types within that application. FOREX has
a unique option where the dealer can enter a letter indicating which NOSTRO should be used, these
equate with the input order; so the first FX default would be A, the second B and so on.
PAYMENT.STOP – Instructions to stop payments
The PAYMENT.STOP table allows all payment stop instructions to be recorded. These are input
against the account to which they relate. All stop instructions for one ACCOUNT number is maintained
on the same record. The DATA.CAPTURE, TELLER and FUNDS.TRANSFER applications, then use
this record to validate against when processing a cheque.

Charges and taxes can now be collected for the stop payments recorded. Charges can be a valid
charge or commission code from FT.CHARGE.TYPE or FT.COMMISSION.TYPE and can be
defaulted from the PAYMENT.STOP.TYPE or can be defined by the user for the particular stop
payment. If a tax is associated with these charges then the tax is also booked. When the
WAIVE.CHARGE field is set to ‘NO’ or holds no value then the charges can be defaulted from the
above PAYMENT.STOP.TYPE as given below.
Figure 111

Figure 112 Stopping Payments
SWIFT MT111
SWIFT message MT111 (Request for Stop Payment of a Cheque) can be produced from the
application EB.MESS.AGE.111.
Incoming SWIFT MT111 is processed using OFS.GLOBUS.MANAGER and a PAYMENT.STOP

record is automatically created.

SWIFT MT112
SWIFT Message MT112 (Status of a request for Stop Payment of a Cheque) is produced from the
PAYMENT.STOP application, via Soft Delivery.
Setting the field RAISE.ACTIVITY to ‘Yes’ will:
1. Allow input to be made in the following fields-

DATE.OF.ISSUE
ACTION.DATE
OUR.REFERENCE
MESSAGE.REC
PAYEE
ANSWERS.
2. Populate the following system Delivery fields -

MT112.CHEQUE.NO
MT112.AMOUNT
3. Raise a Delivery Activity.
Inward MT112 will be directed to Print by the system.

PAYMENT.STOP.TYPE
Reasons for stopping a payment.
The PAYMENT.STOP.TYPE table allows the definition of up to 99 reasons for stopping a payment
(e.g. Cheques Lost, Cheques Destroyed etc.).
The table is used by the PAYMENT.STOP application to describe the reason for each stop instruction.
Charges can now be defaulted from PAYMENT.STOP.TYPE.
Figure 114

Figure 115 PAYMENT.STOP.TYPE
When the payment stop record is authorised the details of the charges and taxes collected are moved
to a live file PAYMENT.STOP.BALANCES whose id is the same as the PAYMENT.STOP file.

Figure 117 PAYMENT.STOP.TYPE
Charges can be waived by inputting a ‘YES’ in the WAIVE.CHARGE field.

Figure 119 Waive charges on PAYMENT.STOP
Inputting a value of ‘YES’ in the STOP.END.FLAG field can revoke an authorised stop payment.

Figure 121 Revoking a PAYMENT.STOP
The details of the revoked PAYMENT.STOP are populated in PAYMENT.STOP.HIST.

PAYMENT.STOP.HIST.

Figure 123 History of stopped payment

CHEQUES. STOPPED
The stopped cheques are written in the format ACCOUNT NO.*CHEQUE NO individually for each
cheque as depicted below.
CHEQUE.NUMBER
ACCOUNT.NO
Figure 124 CHEQUE.STOPPED FILE
Earlier, the cheques presented as stopped are written to the PRESENTED.CHQS and STOPPED.CHQS
fields of CHEQUE.REGISTER.
Now with the introduction of concat files like CHEQUES.STOPPED and CHEQUES. PRESENTED –
CHEQUES.PRESENTED, these fields are not updated in the CHEQUE.REGISTER. Only the used
cheques field is updated to arrive at the number of cheques in hand.

CHEQUES.PRESENTED
A CHEQUE can be presented through TELLER, FT OR DC for encashment-or DC for encashment,

which may be either cash, transfer to an account or an incoming clearing debit. When a transaction
takes place the system will write the cheque so presented in CHEQUES.PRESENTED as shown
below:-
ACCOUNT.NUMBER CHEQUE.NUMBER
CHEQUE.TYPE
Figure 125 CHEQUES.PRESENTED
RETURNED CHEQUES however continue to be written to the CHEQUE. REGISTER.
REVOKING PAYMENT.STOP
Earlier to this development –REVOCATION/ WITHDRAWL of payment stop was handled through field
called STOP.END.FLAG and the associated field called APPLY.DATE which is defaulted to the
system date once the STOP.END.FLAG is entered as YES. The withdrawal instructions for a single
cheque when the STOP.PAYMENT instructions contains a RANGE was not possible earlier. Now
with the introduction of 3 new fields the above difficulty is overcome.
Three new fields have been added in the payment stop file are:-file:

(A) MOD.PS.CHQ.NO Cheque number for which payment stop instructions have to be
revoked is input here.
(B) MOD.CHQ.TYPE Indicates the cheque type to which the above cheque
belongs to.
(B) MOD.CHQ.TYPE Indicates the cheque type to which the above cheque belongs.
(C) MOD.PS.DATE The date from which such REVOCATION is applicable.
After the enhancement the newly introduced field MOD.PS.CHQ.NO will have a drill down facility which
lists the cheque numbers that have been stopped for that particular account number (since the
account number is the id in PAYMENT.STOP. FILE]of the PAYMENT.STOP file).
The user will have the option to revoke the stop payment instructions for a particular cheque number
or a range of cheque numbers at his discretion.
After revocation of the stop payment instructions– the data is written to PAYMENT.STOP.HIST as was
the work flow earlier.

NETTING.PARAMETERS
The NETTING.PARAMETERS application controls the payment netting facility. Only one record may
exist (with the id of the system). It specifies the TRANSACTION codes to be used for netting
payments, the number of days prior to the payment value date that netting records should be created,
and the period that history should be kept before netting information is purged from the system.

Figure 126 NETTING.PARAMETERS

NETTING.AGREEMENT
NETTING.AGREEMENT
The NETTING.AGREEMENT application contains agreements with counter parties to net payments of
the same currency and value date. One agreement can be made with each counter party
(CUSTOMER) and the agreement may specify that only payments of particular currencies may be
netted and only payments arising from particular T24 applications may be netted.
The agreement lasts for a finite period as specified in the start and end date fields. The agreement
may be input and amended at any time.
Figure 128
NETTING.AGREEMENT
Figure 130 Example of NETTING.AGREEMENT

NETTING.ENTRY
The NETTING.ENTRY file contains details of all individual payments that are netted. The id of the
records is the original contract id. The record contains details of each payment arising from the
contract where the payment is being netted.
Figure 131 NETTING.ENTRY
The NETTING.ENTRY record also holds details of the status of each individual payment. Each
individual payment can have one of two statuses -statuses; ‘waiting to be included in a net payment’
and ‘included in a net payment’. The status is recorded in the field NP.REF. If this field does not
contain a value then the individual payment is waiting to be netted. Once the individual payment has
been included in a net payment then this field will be updated with the reference of the NETTING
record.


CREATE.NETTING
This application is used to create netted payments on-line. Verification of a CREATE.NETTING record
will activate the payment netting process. This will combine all outstanding payments that match the
specified criteria into NETTING records. These can then be reviewed, amended if necessary, and
authorised thus creating the net payments.
Payments can be netted for any combination of counter-party, currency and value date. Thus a record
can net all outstanding payments for a single counter-party, only those for a single currency for that
counter-party etc. The specification of counterparty is mandatory.counter-party is mandatory.
Figure 133 CREATE.NETTING - Example of CREATE.NETTING record

NETTING
The netting application is used to review, and modify if necessary, net payments. T24 creates
NETTING records automatically during the overnight batch run or on-line using CREATE.NETTING.
These records are created with a status of ‘hold’ ready for review and possible input. Once a
NETTING record has been confirmed as being valid (possibly following confirmation with the
counterparty)counter-party), it should be authorised. T24 will then generate the single net payment.
Figure 135 NETTING
- NETTING
Settlement details, such as bank to bank-to-bank information, may be added to the NETTING record
and will be used on the resultant net payment. Additionally individual payments may be removed from
the netting record if necessary by using the NETTING field. Payments removed from the record will
remain in suspense until another netting record is generated (either in the T24 batch or by the
CREATE.NETTING application).


Internal Files
ACCT.ACTIVITY - History of account activity
This is an internal file containing details of account balances and activity, used to calculate interest
and charges. It is also used in the calculation of average balances in the Management Information
module.
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. Full details of all balance
changes are included as well as details of transaction activity by transaction code.
Figure 137 Record of account activity

ACCT.AVAILABILITY - History of availability of funds on Accounts
This is an internal file containing details of account balances, activity and availability of funds used in
penalty charge processing. It is also used in the correct implementation of some rules that place
restrictions on the movements on the accounts. These rules are specified on the
ACCT.GROUP.CONDITION application.
Figure 139 History of funds availability
Details are held in separate records for each account.

INTEREST & CHARGES
Interest & Charges
Introduction
The Interest and Charges system is part of the essential core of T24 and it is used to define and
calculate the credit and debit interest, and charges on the ACCOUNT records within the database.
Interest and charges are only applicable to customer ACCOUNT records. These are calculated in the
Close of Business processing and applied to the accounts at user-defined intervals.
ACCOUNT records can be defined into logical groups with different debit and credit interest conditions
applied only to those groups. However, it is also possible to define special conditions, which apply only
to an individual account within a group.
Group And Special Conditions
Conditions for the calculation and application of interest and charges are specified for groups of
accounts and can be overridden with special conditions for individual accounts.
Account groups are determined automatically on the basis of CUSTOMER and ACCOUNT details.
The criteria used and their order of priority are stored in the user-defined tables,
CONDITION.PRIORITY and ACCT.GEN.CONDITION.

Interest Calculations
Interest may be calculated on a daily, average, or highest/minimum balance basis using value dated
balances.
A further restriction can be imposed on the minimum balance calculation, by calculating the interest on
the minimum balance between two dates (for example – between 10th and the last day of the month,
both days included). These dates can be customised at account or group level, in the applications
ACCOUNT.CREDIT.INT &and GROUP.CREDIT.INT.
For example, assume a credit balance on the 31st of the month of 2,500 and an Account Interest
record, which specifies an applicable rate of 10 per cent to be calculated on a MINIMUM balance. If
the following account balances have been recorded for the account in ACCT.ACTIVITY:
Figure 141 Example transactions
If no dates are specified then on the 31st the account will receive a payment of interest calculated on
100 at 10%. However, if the interest is to be calculated on a minimum balance for a specified period
within the account capitalisation period, i.e. for a starting date of 10th and an end date of 31st, then the
account will receive a payment of interest calculated on 500 at 10%.
Accounts opened or closed after or before the start date of the specified range can be customised not
to accrue any interest for that period. These flags can be customised at account or group level, in the
applications ACCOUNT.CREDIT.INT &and GROUP.CREDIT.INT.
The movements/balances on different accounts in the same currency can be combined and interest
calculated on the net result.
Rates can be fixed or linked to basic rates plus or minus a margin.
Different rates can be specified for different balance levels and may be linked to the same or different
basic rates. The rates may apply to the whole of the balance or to the part between two balance levels.

Using group level conditions, it is possible to specify limits on individual accounts so that one rate can be
charged up to the limit and another rate when the limit has been exceeded.
Interest can be calculated on a 360/360, 366/360, 366/366, 360/366, 366/365, 366/364 and 360/365 days
basis.
Back valued entries generate automatic adjustments to previously calculated interest. For any accounts
where interest conditions or rates are changed with effect prior to the last interest application, the system
generates adjustments on request.
Interest Application and Accrual
Interest may be applied daily, every working day, every 1-91-9 weeks, twice a month on the 15th and
the last day or every 1-991-99 months on any day of the month. The application dates can be
specified at group or account level. Cycles may be different for debit and credit interest.
Special interim applications may be requested without affecting the regular cycle.
It is possible to defer debit interest and / or charge application and/or charge applications to an
account in T24 in order to provide the facility of Pre-Notification to the customer. This facility has been
discussed as another heading in this section.
Daily accrual
It is possible to accrue interest normally on a monthly basis and specify certain types of ACCOUNT
with daily accrual. Daily accrual can be set for local currency accounts, foreign currency accounts or
both using the DAILY.ACCR.ALLTYPE field on the ACCOUNT.ACCRUAL record. Alternatively daily
accrual can be set for specific categories or accounts using the DAILY.ACCR.CATG and
DAILY.ACCR.TYPE fields.

Waiving of credit interest
It is possible to waive credit interest depending on the number and type of transactions passed over
the account. The feature is controlled with the help of the fields TXN.THRESHOLD, TXN.CODE.GRP
&and WAIVE.CR.INT. This has been illustrated below:
Figure 143 Transaction restrictions linked to waiving of credit interest
As shown in the above figure all accounts that belong to the group ‘1’ denominated in USD will check
if a transaction code ‘2’ was passed on the account. If this is the case then credit interest on the
account will be waived. (Note only calculations will be performed and stored on the INFO.ACCT.CR
and INFO.ACCT.CR2 files in such a case).
Details on the status related to the above will be stored on the AC.VIOLATION file as illustrated below:

Figure 145 Account Violations

Special Cases
Interest may be paid or received from another ACCOUNT in the same currency.
Credit interest may be calculated for the purpose of offsetting debit interest only and not for application.
In this case debit and credit interest application dates must be the same.
Interest may be suspended for specific accounts, i.e. not posted to profit and loss.
It is possible to calculate interest for information only and not accrue or apply it, e.g. for NOSTRO
ACCOUNT records.
Detailed interest statements may be printed for specified ACCOUNT records whenever interest is
applied.
Interest Related Charges
Tax on interest is calculated at application time.
Certain additional charges based on the debit interest application may be applied on the same date,
these include:
DEBIT.INT.ADDON a percentage of the amount of debit interest to be applied.
GOVERNMENT.MARGIN an additional interest rate applied to each debit interest

calculation.
HIGHEST.DEBIT a percentage of the largest debit balances.
INTEREST.STATEMENT a charge for providing a detailed interest statement when

debit interest is applied.

ACCOUNT maintenance charges
ACCOUNT maintenance charges may be levied monthly, quarterly, six monthly or yearly, always at
the end of the appropriate month. The same application cycle is used for all ACCOUNT records. There
are two main types of charges as follows:
Balance based:
A flat charge can be levied if a certain average or minimum balance is not maintained. A range of
charges for different balances may be specified.
Transaction based:
Charges can be made for the transactions passed over an account. These may be based on the
number or the volume of transactions and may be different for debit and credit or for each transaction
type. Each transaction type may be included or excluded from the calculations. The various types of
transaction charges are as follows:
• Number of credit
• Number of debit
• Turnover credit
• Turnover debit
• Transaction type
Charges may be combined into one account entry or applied separately. Free, minimum and
maximum amounts can be specified for each charge.
Separate charges can be defined for specific currencies and local currency charges used as the
default for all non-specified currencies.

Offsetting And Waiving Charges
On specified ACCOUNT records, charges may be calculated for information only and then waived.
Charges may also be waived if a certain average or minimum balance is maintained, if the amount of
the charge is below a value worth charging or if the account has been into debit.
It is possible to specify that charges do not apply to foreign currency ACCOUNT records.
Notional credit interest can be calculated and offset against the charges.

Pre-Notification of debit interest and / or charges
The ‘Code of Good Banking Practice’ in the U.K sets out standards of services that customers should
be able to expect from their banks. One element of the code is that the bank should give all private
individual customers 14 days notice before debiting their accounts with interest and/or bank charges
relating to overdrafts.
Debit interest and charges are calculated on the capitalisation date, the positing of the amounts to the
customer account may be deferred for a number of days (e.g. 14 days). In this case the interest and/or
charges are posted to a suspense account on the capitalisation date, then posted to the actual
account (and backed out of suspense) on the deferred date. Where interest and/or charges are
deferred the details of the calculations are held in the application AC.PENDING, which allows
adjustment of the amounts.
The number of days by which debit interest and/or charge related debit amounts scheduled for posting
to accounts are to be deferred is specified in the ACCT.GROUP.CONDITION application. This also
controls the suspense account category and is used for deferring interest/charges.
Figure 147 Pre-notification of Interest and Charges

Subsequent corrections performed on accounts will take place on the next capitalisation date.
The pending debit interest and/or charges will be transferred from the suspense accounts to the actual
accounts after the notice period has been served (i.e. during the Batch run of the deferral date).
The amounts of debit interest, charges and, if applicable, taxes will be stored in a standard T24
application AC.PENDING that will be accessible to all types of reports and enquiries. It will be possible
to make adjustments to, or even waive completely, the debit interest and /or charges pending on the
account. This has been illustrated below:
Figure 149 Manual adjustments to pending Interest and Charges

Figure 151 Narrative on pending interest and charges
Generating Charges as Independent Transactions
To generate charges as independent transactions either to request payment of charges, interest

and/or other expenses or to advise of a debit/credit to the account owners’ account, you can use the
application, AC.CHARGE.REQUEST. It will post the accounting entries and/or generate MTn90 or
MTn91 SWIFT messages where appropriate.
There are four options available with this application.
ADVICE This raises a

MTn90 advising a customer of a charge, interest or adjustment, already debited from their
account. No accounting entries are produced from this transaction.
ADVICE This raises MTn90 advising a customer of a charge, interest or adjustment,

already debited from their account. No accounting entries are produced from
this transaction.
BOOK This
raises accounting entries when payment of an unknown charge is received.
BOOK This raises accounting entries when payment of an unknown charge is received.
CHARGE This
can raise both accounting entries and Swift MTn90/MTn91
CHARGE This can raise both accounting entries and Swift MTn90/MTn91
REQUEST This
raises a MTn91 requesting charges, interest or other expenses from another financial institution, which
were previously unknown to them. No accounting entries are produced from this
transaction.
REQUEST This raises a MTn91 requesting charges, interest or other expenses from another
financial institution, which were previously unknown to them. No accounting entries
are produced from this transaction.
You must always set the STATUS field to PAID if accounting entries are required, as this is the status
that generates the entries.
The status options are:
PAID This triggers accounting entries to be raised.
TAKEN Account entries for the charge have been raised via another application.
UNPAID Awaiting payment.
W/O If the charge request is refused.
When the STATUS is UNPAID, the transaction will stay on the live file indefinitely. All other statuses
will put the transaction to the history file during the Close of Business process.

Example 1:
The following scenario would be one example where a bank would wish to raise a charge, in this case
an MT191 (Charges as a result of a payment order).
William Gates, has received a Customer Transfer from Barclays, London (via BIC BARCGB22), with
instructions to advise the Beneficiary by telephone. Barclays Bank London now requests William
Gates to pay the telephone charges to its account with Barclays Bank, New York.
The user would enter a REQUEST.TYPE of “REQUEST” against the account that William Gates hold
with them in the local currency and for a “1” MESSAGE.SERIES with a CHARGE.DETAIL of “PHON”
and with the BIC code for Barclays Bank New York entered into the ACCOUNT.WITH.BANK field. The
ORDERING.INST would of course be Barclays Bank London.
Figure 153 AC .CHARGE.REQUEST

Figure 155 AC. CHARGE.REQUEST

Example 2:
In the next example William Gates requests Citibank Los Angeles to place a stop on payment on its
cheque number 9100089. Barclays Bank confirms the handling charge (USD 20) associated with this
request via an MT190 to Citibank New York, for which it services a USD account.
Figure 156 Paid charge

Savings Accounts
An ACCOUNT can be classified as a Savings account (see ACCOUNT.CLASS) using the CATEGORY
field. A savings account can be issued a passbook, instead of regular statements and be subject to
additional conditions of withdrawal notices etc. (see ACCT.GROUP.CONDITION).

Parameter Files
The following Parameter files have to be set up before the interest and charges can be activated. In
fact, it will not be possible to open any CUSTOMER ACCOUNT records before the Parameter files
and the debit and credit interest conditions have been set up in the database.
All interest and charges conditions defined are based on an effective date that is part of the key of the
record. Modifications to any existing records will have to be done carefully since the conditions defined
will be applicable from the effective date. Therefore a change in the interest rate will have to be
reflected by opening a new condition record from the date the change is applicable rather than
modifying an existing record.

CONDITION.PRIORITY
This application defines which fields from CUSTOMER and ACCOUNT are to be used for setting
various group conditions. The bank must work out which criteria are required for use particularly for
ACCOUNT conditions. For details, please refer to the User Guide on System Tables.
Figure 158 CONDITION.PRIORITY

ACCT.GEN.CONDITION
Every group of ACCOUNT records that the Bank wants to classify is defined in this application. This
classification will be based on the conditions defined in the application CONDITION.PRIORITY.
The purpose of this table is to define the rules for grouping together ACCOUNT records for which the
same interest and charges conditions apply.
Conditions for the calculation and application of interest and charges may then be specified for the
groups and overridden with special conditions for individual ACCOUNT records.
Account groups are determined on the basis of CUSTOMER and ACCOUNT details. The priority data
items from CUSTOMER and ACCOUNT applications are specified in the CONDITION.PRIORITY file
in the record whose ID is ACCOUNT. The priority data items which are used in the
ACCT.GEN.CONDITION records are defaulted from the CONDITION.PRIORITY record with ID
ACCOUNT. For further details regarding XXX.GEN.CONDITION applications, please refer to the User
Guide on System Tables.
Each general condition record specifies the combination of field values defining one account group.
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, a suitable general condition record must exist in order to
determine the Group to which the ACCOUNT belongs, also a capitalisation frequency record, debit
and credit interest conditions (in the CURRENCY of the account)ACCOUNT) for that group must have
been defined.
Whenever input to an ACCOUNT record occurs, a condition group value is recalculated according to
the details held in this table. Amending an ACCOUNT or CUSTOMER record may result in new
interest conditions being applied and possibly an adjustment to interest previously calculated.
If the details of an account match more than one general condition record, the priority order is used to
determine the group. (The higher priority field with a match wins. Priority 1 is the highest priority.)
An overall default condition (no value specified in any field) must be the first ACCT.GEN.CONDITION
record loaded.
The example below illustrates that the group number 4 (Savings Account (Small Business)) is defined
as any ACCOUNT opened in the system with a category code of 6001 having a customer number
whose sector code is 4200.

Figure 160 Conditions linking accounts to account groups

ACCOUNT.ACCRUAL
This is a parameter file used to define the interest accrual and posting conditions in the Bank.
Typically data like accrual cycles (Daily, Monthly etc.), foreign or local currency accruals are specified
in this application. The actual interest and charges rates applicable to each ACCOUNT are defined in
other files.
The purpose of this table is to provide the system with information at COMPANY level, about how and
when to process accruals of interest and charges on customer ACCOUNT records. Also, 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.
Interest accruals may be processed daily or monthly on any day of the month. Account charges may
only be processed at calendar month end.
It is possible to accrue interest normally on a monthly basis and specify certain types of account with
daily accrual.
Dates for interest capitalisation are specified at group level in the GROUP.CAPITALISATION table
and for a specific ACCOUNT in the ACCT.CAPITALISATION table.
Figure 162 Account Accrual parameters

Debit Interest Conditions
Debit interest conditions can be defined either at group level (i.e. for a group of ACCOUNT types) or at
an account level if the debit interest conditions for the Account are different from those of the group it
belongs to.
Tax can also be taken on debit interest.
Charges are included as part of the debit interest conditions.

GROUP.DEBIT.INT
This file defines the group level debit interest conditions for all the ACCOUNT records in a group. T24
allows definition of two debit interest conditions to be applicable on an
an account.
The file also allows the user to specify the calculation method of debit interest for groups of accounts
and provides the link to the GENERAL.CHARGE table where the charges applicable to the same
group are defined. Interest can be calculated on a Daily, Average, or Highest balance basis using
value-dated balances. Rates can be fixed or linked to basic rates plus or minus a margin. Different
rates can be specified for different balance levels and may be linked to the same or different basic
rates. The rates may apply to the whole of the balance or to the part between two balance levels.
Using group level conditions, it is possible to use the limits on individual ACCOUNT records as the first
level for debit interest so that one rate can be charged up to the limit on any ACCOUNT and another
rate when the limit has been exceeded. (Limits for an individual ACCOUNT are specified in the
ACCOUNT.DEBIT.LIMIT). In this case a maximum of 2 rates may be specified.
For example it is possible to have one debit interest calculated on the daily balance at 10% and
another one on the average balance at 12%.
This can be linked to the TAX table to take a tax on the debit interest. This can be linked to
TAX.TYPE.CONDITION to take a tax on the debit interest. Tax key identifies either a tax record in
TAX or TAX.TYPE.CONDITION record with a "*" symbol prefixed to a valid TAX.TYPE.CONDITION
which specifies the calculation and processing of tax, applicable to debit interest. If a
TAX.TYPE.CONDITION record is given then tax is calculated for the account identified by its group
formed by combinations of Residence, Sector code and Nationality (defined in
TAX.GEN.CONDITION). Input of TAX.TYPE.CONDITION will deduct tax at applicable rate for the
customer. Refer to the User Guide chapter for System Tables for further details.

Figure 164 Debit Interest Conditions
Figure 166

MINIMUM DEBIT INTEREST
Minimum Debit Interest

It is possible through fields on the GROUP.DEBIT.INT application to allow for a minimum debit interest
to be specified. The field DR.MIN.VALUE holds the minimum debit interest amount that should be
applied to an account or below which the debit interest should be waived. When the calculated amount
is below this value it is waived when DR.MIN.WAIVE is set to “Yes”. Otherwise the minimum value is
applied. The field DR2.MIN.VALUE holds the second minimum debit interest amount that should be
applied to an account or below which the second debit interest should be waived. When the calculated
amount is below this value it is waived when DR2.MIN.WAIVE is set to “Yes”. Otherwise the second
minimum value is applied.

ACCOUNT.DEBIT.LIMIT
This table allows overdraft limits to be specified for individual ACCOUNT records, which can then be
used as the LIMIT for the first rate of debit interest specified in the appropriate GROUP.DEBIT.INT
condition.
If a GROUP.DEBIT.INT record contains 2 rates, but no DR.LIMIT.AMT for the first rate, the overdraft
LIMIT specified for each ACCOUNT in this table is used as the DR.LIMIT.AMT for the first rate.
In this way it is possible to specify a different DR.LIMIT.AMT for the first rate for each ACCOUNT,
without having to specify separate ACCOUNT.DEBIT.INT 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.
Figure 167 Account Debit Limit


ACCOUNT.DEBIT.INT
ACCOUNT.DEBIT.INT
Any ACCOUNT that has a special set of debit interest conditions different from the group it belongs
to has to be defined in this file. When the interest is processed, T24 will check this file to see if a
particular account has special conditions defined and if not will use the general conditions for the
group the account belongs to.
This can be linked to the TAX table to take a tax on the debit interest. Refer to tax in the chapter on
System Tables for details. This can be linked to TAX.TYPE.CONDITION to take a tax on the debit
interest. Tax key identifies either a tax record in TAX or TAX.TYPE.CONDITION record with a "*"
symbol prefixed to a valid TAX.TYPE.CONDITION which specifies the calculation and processing of
tax, applicable to debit interest. If TAX.TYPE.CONDITION record is given, then tax is calculated for
the account identified by its group formed by combinations of Residence, Sector code and Nationality
(defined in TAX.GEN.CONDITION). Input of TAX.TYPE.CONDITION will deduct tax at the applicable
rate for the customer.
This file is also used to process the charges applicable to the account. Refer to GENERAL.CHARGE
for details.
Figure 169 Individual account debit interest conditions


GENERAL.CHARGE
GENERAL.CHARGE
This application provides the link between all the different charges in T24 to the ACCOUNT conditions
and is used to specify for account groups which charges are to be levied and what balance overrides
are allowed. The GENERAL.CHARGE record applicable to a particular account is specified in the
relevant GROUP.DEBIT.INT or ACCOUNT.DEBIT.INT record.
There are basically two types of charges within T24:
• Interest related
• Ledger Fee
Interest related charges are processed when the interest is capitalised or accrued. Ledger fee charges
are typically calculated at Monthly, Quarterly, Half-yearly or Yearly frequencies as defined on the
COMPANY record.
If the account has maintained a higher balance than that specified, calculated charges can be waived.
Separate sets of balance level details are specified for interest related charges and for ledger fee
charges.

Figure 171 Charging regime

Interest related charges include:
• DEBIT.INT.ADDON
• GOVERNMENT.MARGIN
• HIGHEST DEBIT
• INTEREST.STATEMENT
DEBIT.INT.ADDON, GOVERNMENT.MARGIN and HIGHEST.DEBIT are charged when debit interest

is applied. Either DEBIT.INT.ADDON or HIGHEST.DEBIT may be charged but not both.
INTEREST.STATEMENT is levied each time debit interest is applied.

Ledger Fee Charges
Ledger fee charges may be applied Monthly, Quarterly, Half yearly or Yearly as specified in the
COMPANY record, always at the end of a calendar month.
The charges can be based on:
• BALANCE.REQUIREMENT
• NUMBER.OF CREDIT
• NUMBER.OF DEBIT
• TURNOVER.CREDIT
• TURNOVER.DEBIT
• TRANSACTION CODE SPECIFIC
• HIGHEST DEBIT
Either NUMBER.OF.CREDIT with NUMBER.OF.DEBIT can be used to base charges or

TURNOVER.CREDIT with TURNOVER.DEBIT, but not both. It is possible to combine all these
charges into one charge. A notional amount of credit interest may be calculated and deducted from
the charge amount.
A waive marker may be set in ACCOUNT records to indicate that charges should be calculated but not
applied.
No Ledger fee charges are calculated on balances and activity in the month in which an account is
opened or closed, (unless the ACCOUNT.CLOSURE date is the last day of the month).
Transaction code specific charges are applied in accordance with the rest of the charges defined on
the GENERAL.CHARGE record but can also be calculated on a daily basis. The details of the charge
scales are defined on the TRANSACTION.CHARGE application.
The GENERAL.CHARGE record referred to in the relevant GROUP.DEBIT INT record or

ACCOUNT.DEBIT.INT record specifies which of the following interest related charges are applicable
to an account. In each case the rate applicable is that ruling on the date of debit interest application.

Credit Interest Conditions
Similar to the debit interest conditions, credit interest conditions can be defined either at group level or
at an ACCOUNT level.
TAX can be taken on the credit interest paid to the account.

GROUP.CREDIT.INT
This file defines the group level credit interest conditions for all the ACCOUNT records in a group. T24
allows definition of two credit interest conditions to be applicable on an
an account.
Interest can be calculated on a Daily, Average, or Highest balance basis using value-dated balances.
Rates can be fixed or linked to basic rates plus or minus a margin. Different rates can be specified for
different balance levels and may be linked to the same or different basic rates. The rates may apply to
the whole of the balance or to the part between two balance levels.
Using group level conditions, it is possible to use the limits on individual account records as the first
level for credit interest so that one rate can be charged up to the CR.LIMIT.AMT on any account and
another rate when the CR.LIMIT.AMT has been exceeded. (Limits for an individual account are
specified in the ACCOUNT.CREDIT.LIMIT). In this case a maximum of 2two rates may be specified.
For example it is possible to have one credit interest calculated on the daily balance at 10% and
another one on the average balance at 12%.
This can be linked to the TAX table to take a tax on the credit interest. This can be linked to
TAX.TYPE.CONDITION to take a tax on the credit interest. Tax key identifies either a tax record in
TAX or TAX.TYPE.CONDITION record with a "*" symbol prefixed to a valid TAX.TYPE.CONDITION
which specifies the calculation and processing of tax, applicable to credit interest. If A
TAX.TYPE.CONDITION record is given, then tax is calculated for the account identified by its group
formed by combinations of Residence, Sector code and Nationality (defined in
TAX.GEN.CONDITION). Input of TAX.TYPE.CONDITION will deduct tax at AN applicable rate for the
customer. Refer to the User Guide chapter for System Tables for further details.
.

Figure 173 Credit Interest conditions for account groups

ACCOUNT.CREDIT.INT
ACCOUNT.CREDIT.INT
Any ACCOUNT that has a special set of credit interest conditions different from the group it belongs to
have to be defined in this file. When the interest is processed, T24 will check this file to see if a
particular account has special conditions defined and if not, will use the general conditions for the
group the account belongs to.
This can be linked to the TAX table or to TAX.TYPE.CONDITION to take a tax on the credit interest.
Tax key identifies either a tax record in TAX or TAX.TYPE.CONDITION record with a "*" symbol
prefixed to a valid TAX.TYPE.CONDITION.
.
Figure 175 Individual account credit interest conditions

CHARGES
Charges
There are two types of charges that are allowed within T24. They are Interest Related Charges and
Ledger Fee charges.
Interest Related Charges include Debit Interest Add-on, Government Margin, Highest Debit Charge
and Interest Statement Charge. Debit Interest Add-on, Government Margin and Highest Debit are
charged when debit one interest is applied. Either Debit Interest Add-on or Highest Debit may be
charged but not both. Interest Statement Charge is levied each time debit interest is applied.
Ledger Fee Charges
Ledger Fee Charges may be applied monthly, quarterly, half yearly or yearly as specified in the
Company record, always at the end of a calendar month.
The charges can be based on Highest Debit, Balance Requirement, Number of Credits, Number of
Debits, Turnover of Credits, Turnover of Debits and non-immediate transaction charges depending on
the Transaction Codes. Either the number of credits and debits or the turnover figures can be charged,
but not both. It is possible to combine all these charges into one charge. A notional amount of credit
interest may be calculated and deducted from the charge amount.
A special type of ledger fee charge called transaction code based charge may be defined to be
applicable to a specific general charge or to all general charges. These charges are applied in
accordance with the other ledger fee charges but additionally can be calculated on a daily basis.
A waive marker may be set in Account records to indicate that charges should be calculated but not
applied.
No Ledger Fee Charges are calculated on balances and activity in the month in which an Account is
opened or closed, (unless the Account Closure date is the last day of the month).

The GENERAL.CHARGE record referred to in the relevant GROUP.DEBIT.INTEREST record or

ACCOUNT.DEBIT.INTEREST record specifies which of the following interest related charges are
applicable to an Account. In each case the rate applicable is that ruling on the date of Debit 1one
interest application.

DEBIT.INT.ADDON
The purpose of this table is to specify a supplementary flat percentage charge, which is to be applied
to the overdraft (debit 1)one) interest amount calculated by the system on capitalisation date. No
DEBIT.INT.ADDON is possible for debit 2two interest.
DEBIT.INT.ADDON represents the same type of charge as 'Highest Debit' and for this reason they
cannot both be specified for application to any one particular Account.
Figure 177 Charge parameters for DEBBIT.INT.ADDON
Free, minimum and maximum amounts of charge can be specified by currency and default values can
be input for currencies not specified.

HIGHEST.DEBIT
This table allows the specification of a percentage charge, based upon the highest debit balance
recorded on an ACCOUNT during the application period for debit interest (debit 1)one) or during the
application of the ledger fee charges.
Separate charges can be defined for specific currencies, including local currency. A default charge, in
local currency equivalent, can be defined to cover all accounts in currencies not specifically mentioned.
Figure 180 Charge parameters for HIGHEST.DEBIT
The highest debit charge can be treated as a ledger charge taken on the charge frequency defined in
the Company application. In making a calculation for the charge a provision is made to allow the
charge to be calculated for an entire charge period or monthly within the charge period.
The field called HIGHEST.DEBIT.CH on the GENERAL.CHARGE application allows for the
specification of a highest debit record id. Any charge id linked to this field will be calculated and posted
according to the rules programmed for the charges.
Fields on the STMT.ACCT.CH, ACCR.ACCT.CH and INFO.ACCT.CH records all the information
related to this new charge.

Figure 182 Linking a Highest Debit Charge to a charge regime

GOVERNMENT.MARGIN
GOVERNMENT.MARGIN
GOVERNMENT.MARGIN is a 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. However, it is possible to specify
minimum and maximum amounts for specific currencies as well as local currency equivalent amounts,
which apply to all other currencies.
If there are no overdraft balances during the debit interest capitalisation period, no Government
Margin charge is made.
Figure 183 Charge parameters for GOVERMENT.MARGIN

INTEREST.STATEMENT
INTEREST.STATEMENT
The purpose of this table is to specify a flat fee, which is levied at the time of capitalisation of debit
interest. Specific charges can be entered by currency. For all currencies not specifically mentioned, a
default charge can be entered in local currency equivalent.
The GENERAL.CHARGE record referred to in the relevant GROUP.DEBIT.INT record or

ACCOUNT.DEBIT.INT record specifies which of the following ledger fee charges are applicable to an
ACCOUNT and whether each charge should be applied to the account as a separate entry, or
combined into one entry with other ledger fee charges.
All ledger fee charges are applied on the same day, monthly, quarterly six, monthly or yearly, at the
end of the appropriate month, as specified in the COMPANY record. In each case, the details
applicable are those ruling on the date of the charge's application.
Figure 185 Charge parameters for INTEREST.STATEMENT

BALANCE.REQUIREMENT
BALANCE.REQUIREMENT
The purpose of this table is to define a fixed ACCOUNT charge to be applied if a specified balance is
not maintained.
A range of charges for different balances may be specified.
The required balance may be defined as the minimum or average balance over a given period.
The charge is applied monthly, quarterly, six monthly or yearly as specified in the COMPANY record.
The GENERAL.CHARGE record specifies whether the calculation is in one step, covering the
balances over the whole period, or in monthly steps, applying the appropriate charge for each month
during which the required balance is not maintained.
Figure 187 Charge parameters for BALANCE.REQUIREMENT


NUMBER.OF.CREDIT
This table allows a fixed charge to be specified for each chargeable credit entry, which passes over an
ACCOUNT during the capitalisation period. Alternatively, the TURNOVER.CREDIT table may be used
to specify a charge expressed as a percentage of the total value of the entries. Only one of these two
types of charges can be specified for each account.
Entries are chargeable only if the record on the TRANSACTION table corresponding to the transaction
code in the entry contains 'Y' in the TURNOVER.CHARGE field.
If the associated GENERAL.CHARGE record indicates that charges for debit and credit entries should
be combined, the total number of chargeable entries is calculated and then the details from the
NUMBER.OF.CREDIT tables are used.
The amount per entry, and free, minimum and maximum amounts may be defined for specific
currencies. Default amounts in local currency equivalent may also be defined and are used for
accounts in currencies for which no amounts are specified.
Figure 189 Charge parameters for NUMBER.OF.CREDIT


NUMBER.OF.DEBIT
NUMBER.OF.DEBIT
This table allows a fixed charge to be specified for each chargeable debit entry, which passes over an
ACCOUNT during the capitalisation period. Alternatively, the TURNOVER.DEBIT table may be used
to specify a charge expressed as a percentage of the total value of the entries. Only one of these two
types of charges can be specified for each account.
The details of this table are exactly the same as the NUMBER.OF.CREDIT table. If the associated
GENERAL.CHARGE record indicates that charges for debit and credit entries should be combined,
the total number of chargeable entries is calculated and then the details from the
NUMBER.OF.CREDIT table are used.
Figure 191 Charge parameters for NUMBER.OF.DEBIT

TURNOVER.CREDIT
This table is used to specify a percentage charge on the total value of chargeable credit entries, which
pass over an ACCOUNT during the capitalisation period. Alternatively, the NUMBER.OF.CREDIT
table may be used to specify a fixed charge per entry. Only one of these two types of charges can be
specified for each account.
Entries are chargeable only if the record on the TRANSACTION table corresponding to the transaction
code in the entry contains 'Y' in the TURNOVER.CHARGE field.
If the associated GENERAL.CHARGE record indicates that charges for debit and credit entries should
be combined, the total value of chargeable entries is calculated and then the details from the
TURNOVER.CREDIT table are used.
Free, minimum and maximum amounts may be defined for specific currencies. Default amounts in
local currency equivalent may also be defined and are used for accounts in currencies for which no
amounts are specified.
Figure 193 Charge parameters for TURNOVER.CEDIT

TURNOVER.DEBIT
This 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. Alternatively, the NUMBER.OF.DEBIT table
may be used to specify a fixed charge per entry. Only one of these two types of charges can be
specified for each ACCOUNT.
The details of this table are exactly the same as the TURNOVER.CREDIT table. If the associated
GENERAL.CHARGE record indicates that charges for debit and credit entries should be combined,
the total value of chargeable entries is calculated and then the details from the TURNOVER.CREDIT
table are used.
Figure 195 Charge parameters for TURNOVER.DEBIT

TRANSACTION.CHARGE
This table allows a charge, determined by the TRANSACTION code, to be specified for each entry
that passes over an ACCOUNT during the capitalisation period. These charges may be specified to
be calculated on a daily basis.
The TRANSACTION table specifies which TRANSACTION.CHARGE (if any) is applicable to each
different TRANSACTION code.
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.
If transaction charge needs a complex set up then a valid FT.COMMISSION.TYPE record can be
used to form the basis of THE calculation. A valid FT.COMMISSION.TYPE record is to be given in
field commission key. Category, debit-credit transaction code and tax key is taken from the
TRANSACTION.CHARGE record for processing.
The amount per entry, free amount, minimum amount and maximum amount may be defined for
specific currencies. Default amounts, in local currency equivalent, are used for accounts in currencies
for which no amounts are specified.

Figure 197 Charge parameters for TRANSACTION.CHARGE
Statement Charge based on Channel and Number of Statements
There could be a requirement to set specific charges for the creation of statements, based upon the
channel (print, swift, etc.) by which the statement is transmitted and the number of statements that
have been created for the account during the defined billing period.
The above has been enabled through the Generic Charges to allow definition of generic charges by
Customer, as well as by account. Generic charges process would select accounts by customer as well
as group and subsequently apply the defined charge.
IC.CHARGE
Application IC.CHARGE allows input of a CUSTOMER number as a key, using the prefix ‘C-‘ to
indicate customer, to apply the generic charge to all accounts belonging to the customer.
Generic charge processing selects accounts for an IC.CHARGE key with ‘A-ACCOUNT.NO’, if does
not exist looks for a key ‘C-CUSTOMER.NO’, if does not exist looks for a key ‘G-GROUP.ID-
CURRENCY’ and if does not exist looks for a key ‘G-GROUP.NO’, and if none of the above exists no
charge is calculated for the account.

IC.CHARGE records with key as ‘C-CUSTOMER.NO’ and ‘A-ACCOUNT.NO’ is shown below.
Figure 199 IC.CHARGE shown for a customer with key as 'C-CUSTOMER.NO'
Figure 200 IC.CHARGE shown for an account for the above customer with key ‘A-
ACCOUNT.NO’
ACCT.INTERIM.CHG
Application ACCT.INTERIM.CHG accepts a valid CUSTOMER from the Customer table into the field
CUSTOMER.NO. The ACCOUNT.NO and CUSTOMER.NO fields are mutually exclusive and only one
can be entered. If a CUSTOMER.NO has been entered it would read all the accounts from the concat
file CUSTOMER.ACCOUNT, and default the accounts and the relative charges are multi-valued in the
related fields ACCOUNT.NO, IC.CHARGE.CODE and CHG.PRODUCTS as defined in IC.CHARGE and
clear the CUSTOMER.NO field of any values.

The below screen shots of CUSTOMER.ACCOUNT and ACCT.INTERIM.CHG showing the record
with CUSTOMER.NO field input and the record after the CUSTOMER.NO field value has been accepted
for the customer as defined in the above IC.CHARGE screen shot with key as ‘C-50037’ and key ‘A-
20435’
Figure 201 CUSTOMER.ACCOUNT showing the accounts for the customer defined in
the above IC.CHARGE
Figure 202 ACCT.INTERIM.CHG showing the CUSTOMER.NO field input and not yet
accepted
Figure 203 ACCT.INTERIM.CHG showing the accounts defaulted with the charge
products for the above Customer entered in the CUSTOMER.NO field

The above screen shots show that for customer-50037 interim charges would be computed for
account-20435 based on record A-20435 and for account-20443 based on record C-50037 as defined
in application IC.CHARGE.

GENERIC CHARGES
Generic Charges
Overview
The Generic Charges functionality has been developed to enable local charge requirements, which
are not catered for with the above functionality, to be developed locally and incorporated into the T24
charging suite. It also enables locally developed charges to use a different capitalisation frequency
(as opposed to current functionality where capitalisation frequency is set for all charges on the
COMPANY application). Taxes can be applied on these charges.
As with current charging functionality, charges created through generic charge functionality can be set
at a group and currency level, or at an account level. There is also the functionality whereby charges
are applied at a group level – regardless of the accounts created.
Generic charges are not accrued, only capitalised. Capitalisation frequency for each charge can be set
to monthly, quarterly, half yearly or yearly. Interim capitalisation can also be specified for these
charges.
Set-up of IC.CHARGE.PRODUCT
Figure 204 Structure behind IC.CHARGE.PRODUCT record

The IC.CHARGE.PRODUCT application contains references to the locally developed charges to be

included in the T24 charging mechanism.
As detailed below, the IC.CHARGE.PRODUCT is largely defined through the FT.COMMISSION.TYPE

record. This record may have locally developed routines attached, which in turn may use data from
local tables in order to calculate the correct charges.
FT.COMMISSION.TYPE
FT.COMMISION.TYPE
Charge Routine
Local Charge Routine
IC.CHARGE.PRODUCT
Local Tables
The FT.COMMISSION.TYPE table holds the basic details for the IC.CHARGE. It specifies the P&L
category into which the charges will be paid, the transaction codes which should be used for the
debiting and crediting through the charge, and the routine from which the charge amount is calculated.
As the charge routine is responsible for generating the actual charge amount, fields that would usually
be mandatory such as CALCULATION.BASIS, CURRENCY and CALC.TYPE no longer become
necessary.

Figure 205 FT.COMMISSION.TYPE for generic charges
IC.CHARGE.PRODUCT
The IC.CHARGE.PRODUCT then incorporates the FT.COMMISSION.TYPE field and if necessary,

applies a further routine to calculate the base amount from which the charge should be calculated.
Figure 207 IC.CHARGE.PRODUCT
So in the above example, the IC.CHARGE.PRODUCT record defines the charge product,
ACCT.KEEP.FEE. The FT.COMMISSION.TYPE key, NUMBEROFTXNS is linked to the charge
product. The field BASE.AMT.RTN accepts a routine, that calculates and returns the base amount
(principal) on which charge is calculated. The base amount routine can be developed locally suiting
the client’s requirements.

Set-up of IC.CHARGE
Set-up of IC.CHARGE
The IC.CHARGE table links an account or a customer or a group of accounts with the
IC.CHARGE.PRODUCT records. The charge calculation step period, capitalisation frequency and
effective charge date (the date from which the charge is effective) is specified here. As a result, each
charge product can have its own capitalisation frequency, calculation step period and effective charge
date
Figure 209 Linking accounts to generic charges
The above IC.CHARGE record is set for an account, so that one charge is calculated monthly and
applied annually, while another is calculated and applied every 6 months.
The CHRG.EFF.DATE specifies the date from which the charge is effective. The charge effective date
is defaulted to today. Charges can be waived by specifying value ‘YES’ in the field WAIVE.CHARGE.
Charges can be set for a group of accounts or for a group of accounts with particular currency. For
example, an IC.CHARGE record with an id G-1 would be applied to all accounts within condition group
1. An IC.CHARGE record with an id of G-1-USD would be applied for all accounts within group 1one,
which have a currency of USD. G-1-USD would take precedence over G-1. As detailed above,
individual accounts may be specified where the id is ‘A-<ACCOUNT.NUMBER>, also customer can be
specified where the id is C-<CUSTOMER.NUMBER>. Settings here would take precedence over both
group level settings and group and currency level settings. This is more clearly detailed below :

IC.CHARGE RECORD FOR ACCOUNT GROUP:
Figure 211 Linking account groups to generic charges
The above IC.CHARGE is defined for an account group 1.one. All the accounts falling into this group,
will have this charging structure
IC.CHARGE RECORD FOR ACCOUNT GROUP WITH A CURRENCY
Figure 213 Linking account groups for a specific currency to generic charges

The above IC.CHARGE record is set for an account group1group one and currency USD. This means
that for all the accounts falling into this group with currency USD will have this charging structure. The
two different charge products are attached with different capitalisation frequency (monthly and
quarterly).
ACCT.INTERIM.CHG
Generic charges are usually capitalised at month ends or quarter ends or half yearly or yearly. If
certain charge products that are set on an account needs to be capitalised on a specific date, which is
not the regular capitalisation date, interim capitalisation can be done for that date.
for the customer as defined in IC.CHARGE screen shot with key as ‘C-50037’ and key ‘A-20435’
Figure 215 CUSTOMER.ACCOUNT showing the accounts for the customer defined in the above
IC.CHARGE

Figure 216 ACCT.INTERIM.CHG showing the CUSTOMER.NO field input and not yet accepted
Figure 217 ACCT.INTERIM.CHG showing the accounts defaulted with the charge products for the above
Customer entered in the CUSTOMER.NO field
for the customer as defined in IC.CHARGE screen shot with key as ‘C-50037’ and key ‘A-20435’.

Figure 218 CUSTOMER.ACCOUNT showing the accounts for the customer defined in
the above IC.CHARGE
Figure 220 ACCT.INTERIM.CHG showing the CUSTOMER.NO field input and not yet accepted
Figure 222 ACCT.INTERIM.CHG showing the accounts defaulted with the charge
products for the above Customer entered in the CUSTOMER.NO field

Interest And Charges Processing
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.
If no value date is entered in a transaction, it may be added automatically by the system, depending
on rules specified in the TRANSACTION code table, or rules specified in the application, which
generated the transaction (e.g. MONEY.MARKET).
If no value date has been entered or generated in an entry, a default of the booking date is assumed,
i.e. the entry is considered to affect the balance for interest purposes on the same day as it is
processed.
There is functionality within T24 to apply charges to a customer, depending upon the unutilized/utilised
amount of a LIMIT. When set up, T24 will record the utilized amount, and calculate the unutilised
amount, and record it in contingent account(s), from which interest and charges can be calculated
and applied to the customer account, using standard T24 functionality. As the utilised amount of the
limit varies, so the amounts in the contingent accounts vary and so the interest and charges can be
calculated.

Set-up of Contingent Accounts
ACCOUNT.PARAMETER
The ACCOUNT.PARAMETER file contains the top-level settings for contingent accounts. It is here
that it is specified which CATEGORY codes can be used for contingent accounts, and also which
TRANSACTION codes should be used for the debiting and crediting of the contingent account.
Figure 224 ACCOUNT.PARAMETER using contingent accounts

ACCOUNT.CLASS
Two separate ACCOUNT.CLASS IDs, namely OFFLIMIT and UTILLIMIT are created. They have to
be opened in the ACCOUNT.CLASS application, with appropriate CATEGORY codes, as mentioned
in the ACCOUNT.PARAMETER table. Internal Accounts are to be opened in the categories
mentioned, to post the contra entries.
Group Settings for contingent accounts
Contingent accounts, as they have different reporting and accounting consequences than non-
contingent (typical) accounts, have to be set up to have their own groups. As a result, specific
ACCT.GEN.CONDITION, GROUP.CREDIT.INT, GROUP.DEBIT.INT and GROUP.CAPITALISATION
records must be set up to cater for the contingent accounts. These can be set up in the same way as
contingent account groups are set up.
It is in the application ACCT.GROUP.CONDITION that the group is flagged as being a contingent

account. This is done in the field CONTINGENT.INT. The values permitted for this field are; “B”, to
indicate that non-contingent (on balance sheet) interest is to be generated for this account. The entry
“O” will indicate non-contingent, off balance sheet interest is generated. And “C” that contingent
interest will appear Off Balance Sheet. “I” indicates that the contingent account is internal. The
presence of a value in this field indicates that the account is a contingent account.

Figure 225 Contingent account group
ACCOUNT settings for contingent accounts
When creating contingent ACCOUNT records, it is necessary to indicate to which accounts the
interest and charges generated from the contingent account are applied. These are specified in the
INTEREST.LIQU.ACCT and CHARGE.ACCOUNT fields of the ACCOUNT application. These fields
are mandatory where the CONTINGENT.INT field has been populated. The CONTINGENT.INT field
will be populated by default from the ACCT.GROUP.CONDITION setting (see above). . There are
four different settings at present; “B” (to indicate on-balance sheet interest), “O” (to indicate off-
balance sheet interest), “C” (to indicate contingent interest off-balance sheet) and “I” (to indicate the
contingent account is internal.
LIMIT set-up to enable sweeping of unutilised/utilised amounts :unutilised amounts
LIMIT.PARAMETER
The PROCS.LIMIT.SWEEP field on the LIMIT.PARAMETER application must be set to Y to enable

the unutilized/utilised amount on a limit to be swept into a contingent account. There is also a flag on
LIMIT.PARAMETER, ALLOW.UNUTIL.CR, which determines whether, if part of a limit is then utilised,
whether a credit should be passed to the contingent account to reflect this. . There is another flag on
LIMIT.PARAMETER, DEFAULT.MAX.TOTAL, which determines whether, the INTERNAL.AMOUNT or
the ADVISED.AMOUNT of the LIMIT is to be used for the calculation of Unutilised limit amount.

Figure 226 LIMIT.PARAMETER settings for contingent accounts
Figure 227 LIMIT.PARAMETER settings for contingent accounts

LIMIT
The contingent account to which the unutilized/utilised amount of a limit is to be swept is specified in
the LIMIT application, in the UNUTIL.ACCT/UTIL.ACCT fields. It is from here that the current
unutilized/utilised amounts are taken. There is also the option here of overriding the
LIMIT.PARAMETER application on the setting of whether credits to the contingent account should
occur when the unutilised amount is reduced.

Figure 228 Individual LIMIT settings for contingent accounts
Once set up, the contingent accounts are updated during the end of day. It is also possible to update
the accounts through DATA.CAPTURE and FUNDS.TRANSFER . It is only possible to make a
FUNDS.TRANSFER when both accounts are typical accounts or when both accounts are contingent.
Likewise DATE.CAPTURE the entire batch must be of the same type.

Interest Accruals
ACCR.ACCT.CR and ACCR.ACCT.CR2
These files contain details of the calculation of the credit interest that has been accrued on an
ACCOUNT but has not yet been posted to the account.
The files ACCR.ACCT.CR and ACCR.ACCT.CR2 are similar in layout and denote the CR or the CR2
interest respectively.
ACCR.ACCT.DR and ACCR.ACCT.DR2
These files contain details of the calculation of the debit interest that has been accrued on an
ACCOUNT but has not yet been posted to the account.
The files ACCR.ACCT.DR and ACCR.ACCT.DR2 are similar in layout and denote the DR or the DR2
ACCR.ACCT.CH
This file contains details of the calculation of the charges that have been accrued on an ACCOUNT
but have not yet been posted.

Interest Capitalisation
GROUP.CAPITALISATION
The purpose of this table is to specify the next date and subsequent frequency of application of debit
and credit interest, for a group of Accounts.
Interest may be applied on any day of the month. Cycles may be different for debit and credit interest,
(e.g. debit interest may be charged monthly and credit interest paid quarterly) unless credit interest is
only to be calculated as an offset to debit interest.
The date of debit interest application is also used as the date of application of interest related charges.
(These are DEBIT.INT ADDON,DEBIT.INT.ADDON, GOVERNMENT.MARGIN, HIGHEST.DEBIT and
INTEREST.STATEMENT).
If the 'Last Day Inclusive' field in the ACCOUNT.ACCRUAL file contains 'Y', interest is calculated on
balances with value up to and including the capitalisation date. The value date of the interest entry
booked is the day after the capitalisation date. If 'Last Day Inclusive' contains 'NO' only balances up to
and including the previous working day are included. The value date of the interest entry booked is the
day after the last balance included.
Interest entries are booked to the ACCOUNT on the day they are calculated, or on the next working
day, depending on the application posting day specified in the ACCOUNT.ACCRUAL record.
If the capitalisation date falls on a non-working day, the application is processed on the previous
working day, unless a month end accrual day falls before the capitalisation date, in which case the
application is processed on the next working day. In either case, the calculation is up to the
capitalisation date and the entries generated have the same value date as they would have had if they
had been processed on that date.
Figure 229 Group capitalisation

ACCT.CAPITALISATION
ACCT.CAPITALISATION
This table allows interest capitalisation dates to be specified for individual accounts, overriding the
dates specified for the associated group in the GROUP.CAPITALISATION table.
The details included in this table are exactly the same as the GROUP.CAPITALISATION table.
Figure 231 Account capitalisation
Interest Capitalisation Date
The input into INT.POST.PERIOD on ACCT.GROUP.CONDITION allows the user to define the value
date of interest capitalisation. The actual posting date, which should not be confused with the value
date, of the capitalised interest, is governed by the input in the four frequency fields on
GROUP.CAPITALISATION. The LAST.DAY.INCLUSVIE setting on ACCOUNT.ACCRUAL will
determine whether the interest calculations are inclusive or exclusive of the capitalisation date. If, for
example, Q (Quarterly) is input in INT.POST.PERIOD and LAST.DAY.INCLUSVIE is set to Y (Yes)
then interest will be posted to the account with a value date of the first working day of the next quarter.
If LAST.DAY.INCLUSVIE is set to N (No), and the INT.POST.PERIOD remains the same, then the
value date of the posting will be the last working date of the current quarter period. It should be noted

that once a customer account has been opened in the company the LAST.DAY.INCLUSVIE field
setting cannot be changed.
Assume a system date of 1st July.
Last day inclusive Interest post period Calculation Period end Value date of interest
setting date posting
N M 30th July 31st July
Y M 31st July 1st August
N Q 29th September 30th September
Y Q 30th September 1st October
ACCT.INTERIM.CAP
Used to request interim interest applications on particular ACCOUNT records, without affecting the
normal application cycles. The interim applications requested will be processed during the Close of
Business run on the day specified.
Figure 234 Interim capitalisation

ACCT.SUSP.SETTLE
ACCT.SUSP.SETTLE
Used to request settlement of interest and charges, which have been suspended and not booked to
Profit and Loss. The Close of Business program EOD.ACCT.SUSP removes the requested amounts
from the SUSPENSE.AMOUNT fields in the ACCOUNT record and generates the appropriate entries for
Profit and Loss.
TABLE.CAPITALIS.CORR
Used to request recalculation and correction of previously applied interest. (The system automatically
recalculates and corrects interest when entries with value dates prior to the last interest application are
processed, but does not automatically recognise back-valued changes to interest rates or conditions.)
The requested recalculations are processed during the Close of Business run on the day specified.
Figure 235 Requesting recalculation of capitalisation
This functionality can now be used to generate STMT.ACCT.XX and CORR.ACCT.XX records for
back-valued changes to the balance of an account for both zero interest and interest generating
accounts.
A STMT.ACCT.XX will be produced showing the recalculated balances and interest if applicable.
Whereas the CORR.ACCT.XX will show the original balances and calculations i.e. before the back
valued correction was made.

ENQUIRIES
Enquiries
INFO.ACCT.CR and INFO.ACCT.CR2
These applications may be used to request on-line calculations of credit interest for CR and CR2. The
results are for information only and no entries are generated.
The file layouts for the two files are similar and INFO.ACCT.CR calculates the CR Interest and the
INFO.ACCT.CR2 calculates the CR2 Interest.
The Verify function is used to initiate the calculations.
INFO.ACCT.DR and INFO.ACCT.DR2
These applications may be used to request on-line calculations of debit interest for DR and DR2. The
results are for information only and no entries are generated.
The file layouts for the two files are similar and INFO.ACCT.DR calculates the DR Interest and the
INFO.ACCT.DR2 calculates the DR2 Interest.
INFO.ACCT.CH
This application may be used to request on-line calculations of charges. The results are for information
only and no entries are generated.

INFO.ACCT.PREMIUM
This application may be used to view on-line calculations of premium interests. The calculations are
initiated from an enquiry called ‘INFO.ACCT.PREMIUM’. The results are for information only and no
entries are generated.

ACC.CURRENT.INT
This enquiry may be used to view on-line for an Account any Interest rate changes for a given period.
Figure 237 Rate changes on an account
ENQUIRY FOR GENERIC CHARGES – ACCOUNT.CHG.ENQ
This enquiry is used to view the generic charges for an account or a range of accounts till a given date.

Figure 239 Enquiry for generic charges
The above screenshot shows online calculation of generic charges for account number 17205. It
shows the calculated date till when the charges were calculated, the charge amount, tax amount and
the charge product set and the narrative.

ADVICES
INTEREST RATE CHANGE ADVICES
Interest Rate Change Advices
Print advices to notify Interest Rate Changes on accounts can be generated in T24 during overnight
run. Development of the new functionality is based on Multi threading and this approach should have
the field JOB.NAME for the record ACCT.RATE.CHANGE in PGM.FILE set to
@BATCH.JOB.CONTROL. A batch record called RATE.CHANGE.ADVICE runs between specified
dates in on an ad-hoc basis. Advices for accounts that are subject to interest rate change since last
advice date are produced. The program ACCT.RATE.CHANGE last run date and the next run date in
the batch record are considered and gathered. When it is run for the first time since the batch last run
date has been left blank, the last date advice produced viz.is produced. The advice produced for rate
changes up to that date has been hard coded to be the entry in the field BACK.VALUE.MAXIMUM in
DATES.
The fields RATE.CHANGE.ADVICE and ADVICE.TYPE in ACCT.GROUP.CONDITION needs to be

set to YES and to the relevant valid record in EB.ADVICES respectively, for advices to be produced
for respective accounts in that group. Once these settings are in place, Account number, Account
details and the Interest Rate Changes details are passed on to onto EB.HANDOFF(1),
EB.HANDOFF(2) and EB.HANDOFF(3) respectively to be populated in DE.O.HANDOFF.
To generate the advices, in addition to the above, further relevant parameterisation needs to be in
place in the applications given below
EB.ACTIVITY
EB.ADVICES
DE.MAPPING
DE.PRODUCT
DE.FORMAT PRINT
For further details please refer to the DELIVERY section in the User Guides.
FILES USED
Files Used
ACCT.ACTIVITY
ACCT.ACTIVITY contains details of ACCOUNT balances and activity used to calculate IC 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.

The details held in this file for the calculation of interest include value-dated balances and total debit
and credit turnover for each value date.
The 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.
The value-dated balances are also used for the 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.
This file is updated during the Close of Business process EOD.ACCT.ACTIVITY with the details of
every entry which has been generated during the day and also during the Close of Business
capitalisation processes, EOD.CAPITALIS.CORR and (unless next day posting is specified in the
ACCOUNT.ACCRUAL table) EOD.CAPITALISATION.
A new ACCOUNT activity record is generated every time an entry is encountered with a value date or
booking date in a month in which the account has not previously had any entries.
If an entry has a Value date in a different month from the booking date, at least 2 account activity
records are updated, one containing the value dated balances for interest purposes, the other
containing the numbers and amounts of transactions for charge purposes.
If an entry has a value date earlier than entries that have previously been processed for the same
account, all subsequent value dated balances are updated. This may involve updating several account
activity records.

STMT.ACCT.CR and STMT.ACCT.CR2
These files contain details of the calculation of the credit interest that has been booked to the client
ACCOUNT.
The files STMT.ACCT.CR and STMT.ACCT.CR2 are similar in layout and denote the CR or the CR2

STMT.ACCT.DR and STMT.ACCT.DR2
These files contain details of the calculation of the debit interest that has been booked to the client
ACCOUNT.
The files STMT.ACCT.DR and STMT.ACCT.DR2 are similar in layout and denote the DR or the DR2
Figure 241 STMT.ACCT.DR

STMT.ACCT.CH
STMT.ACCT.CH
This file contains details of the calculation of the charges that has been booked to the client
ACCOUNT.
Figure 243 STMT.ACCT.CH

CORR.ACCT.CR and CORR.ACCT.CR2
These files contain details of the previous calculation of credit interest, which have been capitalised
and recalculated and corrected. The new details are held on the STMT.ACCT.CR and
STMT.ACCT.CR2 files.
The files CORR.ACCT.CR and CORR.ACCT.CR2 are similar in layout and denote the CR or the CR2
Figure 245 CORR.ACCT.CR

CORR.ACCT.DR and CORR.ACCT.DR2
These 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.
The files CORR.ACCT.DR and CORR.ACCT.DR2 are similar in layout and denote the DR or the DR2
Figure 247 CORR.ACCT.DR


ACCR.ACCT.TRAN.CH
ACCR.ACCT.TRAN.CH
This file contains the details of the currently accrued transaction code based charges if these were
defined to be calculated on a daily basis on the TRANSACTION.CHARGE application. Details of
calculated charge amounts are used from this file at the time of capitalising charges, when also these
details are transferred to the STMT.ACCT.TRAN.CH file.
Figure 249 Accruals on transaction charges

STMT.ACCT.TRAN.CH
This file contains the details of the previously applied transaction code based charges. A new record is
stored into this file for every capitalisation date for an account.

Figure 251 Statement of capitalised transaction charges

FILES USED FOR GENERIC CHARGES
This file contains the details of generic charges that have been capitalised to the customer account.
The id of the file is ACCOUNT. NUMBER, CHARGE.PRODUCT.CAPITALISED number charge,
product capitalised date. This file shows full details about the charges and taxes capitalised.

Figure 253 Statement of generic charges
The above diagram shows the STMT.GEN.CHG record for an account 17205. The charge product that
has been capitalised is ACCT.KEEP.FEE on 15/01/2001. The charge and tax information like the
charge amount, IC.CHARGE set for the account, the tax amount, charge and tax category, the
FT.COMMISSION.TYPE (charge code) id attached to the charge product, debit and credit transaction
codes for charge and tax, etc are shown in this record.

END OF DAY
Close of Business
The following programs run the BATCH and their general functions are described below:
INT.POST.NEXT
If interest entries have been generated for posting the next day, these must be processed before any
other ACCOUNT module Close of Business programs.
This Batch job posts interest entries generated during the previous Close of Business run if NEXT is
specified in the application posting day field in the ACCOUNT.ACCRUAL record.
The interest and charges module includes the following programs which must be run during
end-of-day Close of Business processing, after processing any interest entries generated the previous
day and after the Close of Business processes which generates accounting entries for the various
other transaction processing modules. The programs must be run in this order.
EOD.ACCT.SUSP
Settles 'suspended' interest and charges as requested via the table ACCT.SUSP.SETTLE, by
removing the requested amounts from the suspense amounts in the ACCOUNT record and generating
the appropriate entries for Profit and Loss.
EOD.ACCT.ACTIVITY
Updates opening balances in account records and the value dated balances and activity details in the
ACCT.ACTIVITY file used to calculate interest and charges.
It also updates files used by other Close of Business procedures in the ACCOUNT module in printing
account statements and in determining accounts to be included in the overdraft and referral reports

and accounts with back-valued entries, which may require corrections of interest previously, applied
and accounts which may be closed.

EOD.UPDATE.ACCT.ACT
Adds booking date information to the ACCT.ACTIVITY file for any entry made during the day for which
the value date did not equal the booking date.
EOD.CAPITALIS.CORR
Recalculates interest previously applied and generates correcting entries. It automatically processes
any accounts, that have had entries with value dates prior to the last application date, and also
processes any accounts selected via TABLE.CAPITALIS.CORR.

EOD.CAPITALISATION
Calculates and applies interest and charges on regular capitalisation dates (specified in the GROUP
or ACCT CAPITALISATION tables), on any interim application dates selected via
ACCT.INTERIM.CAP and for ACCOUNT records flagged for closure.
DAILY.CHARGES.EOD
Calculates on a daily basis, the charges that have accrued on accounts that have been linked to
transaction code based daily charges.
EOD.REBUILD.ACCT.GRP.COND
Some of the parameters in the ACCT.GROUP.CONDITION file cannot be changed on-line. This is
because a change made to them necessitates rebuilding the ACCT.AVAILABILITY file. Therefore any
changes to be made to these parameters are created into a request record, which carry over the new
values to the active records. This program is responsible for these functions.
EOD.REBUILD.ACCT.AVAIL
The ACCT.AVAILABILITY file is crucial to the correct validations on account transactions. If any of the
parameters governing these validations change, the ACCT.AVAILABILITY file becomes out of sync
and needs to be rebuilt for all of the accounts affected. This program handles the rebuild of the
ACCT.AVAILABILITY file.
EOD.ACCRUAL

Processes accrual of interest and charges on customer accounts, generating entries for profit and loss.
The days on which interest and charges are accrued are specified in the ACCOUNT.ACCRUAL table.
Interest may be accrued daily or monthly (on any day of the month). Charges may be accrued monthly,
at calendar month end, or only booked to profit and loss when they are applied.
DELIVERY
Delivery
The delivery system is used to produce interest statements and interest and charges advices.
Formats, addresses and numbers of copies required are specified within the delivery system. Interest
and charges advice’s may be printed or sent via SWIFT.
The interest and charges module passes the required information to the Delivery system, which
transforms it into the appropriate messages.
The interest statement has a delivery code of 1950 and interest and charges advice’s have the
Delivery code of 1990.

CHEQUE ISSUE & MANAGEMENT
Cheque Issue & Management
Introduction
T24 provides functionality for banks that have requirements to manage the issuing and registration of
cheques and bank drafts issued to their clients.
Banks can record requests for chequebooks ordered by customers and when these cheques are
received from the vendors, issue them to the appropriate customer.
When a chequebook is issued to the client, the range of the cheque numbers will be recorded into a
cheque register. Furthermore, when cheques are stopped or returned, this can also be recorded in
the cheque register. When cheques are presented, this is stored in a CHEQUES.PRESENTED file.
There is also the functionality to charge the client for the issuing of cheque books, for charges to be
applied on the usage of cheques by the customers, and also a periodic charge for possession of a
cheque book.
On the presentation of a cheque, the cheque register is consulted to confirm that:
• The Cheque number is valid for the account on which it is drawn;

• The Cheque has not been stopped by the client
Furthermore, the CHEQUES.PRESENTED file is also consulted to confirm that the cheque has not
already been presented elsewhere.
When a cheque does not conform to the above rules, an override is requested. If the override is
accepted the cheque may still be used.
On completion of the above transaction the cheque register and CHEQUES.PRESENTED file is
updated with the last status on the cheque.
Banks can issue cheques and drafts drawn on them. Details for these are stored in a similar manner
to customer cheques. Further details regarding the following could be obtained from the system if
required.
• The name of the client to whom the cheque/draft was issued.

• The beneficiary of the cheque.

• The amount and currency of the cheque.
• The date and place of issue.
• The cheque number.

Setting up ACCOUNT.PARAMETER
To enable cheque-processing, the CHEQUE.REGISTER field on the ACCOUNT.PARAMETER

application needs to be set to a value of ‘YES’. This has been illustrated as under:
Figure 256 ACCOUNT.PARAMETER for cheque processing

Issuing Cheques to Customers
Setting up a cheque type
The first step towards issuing cheques on accounts is to set up a CHEQUE.TYPE record. This record
will allow you to specify certain default parameters associated with a class of cheques. An example
has been illustrated as under:
Figure 257 CHEQUE.TYPE

Setting up a charging structure for the issuing of cheques
The user can set up the charging rules in the CHEQUE.CHARGE application to levy charges on
cheques issued, cheques used, and also a periodic charge for having the cheque facility, as illustrated
under:
Figure 259 CHEQUE.CHARGE

Linking a transaction code to a cheque type
In order to invoke the processing that will validate cheques issued to a client account, a
TRANSACTION record will need to be linked to the CHEQUE.TYPE created in step 4.3.1.4. The
transaction code used in the accounting entry raised for the cheque transaction must be linked into a
CHEQUE.TYPE record for the system to perform the extra validation associated with cheque issue
and management. An example of this has been illustrated as under:
Figure 261 Linking cheque processing to TRANSACTION code

Issuing & Registering of Cheques
Cheques are issued to clients through the CHEQUE.ISSUE application. This has been illustrated as
under:
Figure 263 Issuing cheques
In the example above the client account 20648 has been issued 100 cheques of cheque type ‘CURR’
on the 6th February 2001. The customer has also been charged $20.00 on the 9th February 2001 for
the issuing of cheques. The cheque numbers will start from 101000 and go up to 101099.

This action would create a cheque register update as shown under:
Figure 265 Cheque register
As seen in the figure above account number 20648 now has cheque 101000-101099 issued to it.
CHEQUE ISSUE STATUS AND RE-ORDER PROCESS
The CHEQUE.ISSUE application will now have additional fields to track the status of chequebook and
handle charges other than cheque-leaf related charges. Attempt has also been made to link this
application to soft delivery by triggering delivery messages on cheque status change. A new table
called CHEQUE.STATUS has been added to store various cheque statuses. The CHEQUE.CHARGE
application has been enhanced to take-in FT.CHARGE.TYPE and FT.COMMISSION.TYPE and this
has been linked to CHEQUE.ISSUE application.
The history of charges debited under various stages and the history of date of statuses will be stored
in CHEQUE.CHARGE.BAL for reference by the Bank.
A way of distinguishing the cheque issued to the customer for the first time from the issues of
subsequent times, for the purpose of defining a different approval mechanism by the Bank.
During EOD,COB, the accounts that have reached the minimum holding level of cheques will be
identified and new cheque issue records will be automatically created with status as defined by user.
Banks can follow this record, for automatic delivery of chequebooks to customers as a re-order
process

Issuing Bank Drafts
Bank drafts and cheques issued by the bank may be registered using the same procedure as that
detailed above, with the difference of using a Nostro account instead of a client account. Thus a new
cheque type for bank drafts would need to be set up (with "Nostro accounts" as the category field),
and a TRANSACTION record to be used when issuing drafts. The TRANSACTION record would have
to have ‘CREDIT’ flagged in the DEBIT/CREDIT indicator (as opposed to debit for client cheques).
No CHEQUE.CHARGE record would be required.
It should be noted that at present it is not possible to run a TELLER or FUNDS.TRANSFER deal
where both sides of the transaction refer to TRANSACTION records where the CHEQUE.IND field is
set to YES. In other words, it is not possible for a client to buy a registered bank draft, using their own
registered cheques.

TELLER using cheque number
It is now possible to pass a TELLER transaction that debits the account number on which the cheques
were issued. The system will respond with overrides when cheques that have already been presented
or stopped are presented on a transaction.

Presenting a cheque presented earlier
The following screen shot depicts how the system responds when attempting to present a cheque
already presented earlier to the system.
Figure 267 Cheque already presented
This is because in the CHEQUES.PRESENTED file there is already a record of this cheque having
been used. If we say Yes to the override, the CHEQUES.PRESENTED file gets updated, and the
REPRESENTED.COUNT field is updated. :

Figure 269 CHEQUES.PRESENTED
Stopped Cheques
In order to stop cheques the user will need to enter a PAYMENT.STOP record for the account number
on which the cheque has been issued (see section 0). This is done as shown under: The
PAYMENT.STOP record must be authorised before the stop comes into effect.
Figure 271 Stopping a cheque


This action would update the CHEQUE.REGISTER file as shown under:
Figure 273 Stopped cheque recorded on the cheque register

Now when an attempt is made to use a stopped cheque on a transaction the system responds with an
override message that has been illustrated in the figure below:
Figure 275 Attempted presentation of a stopped cheque

If the answer to this override were ‘Y’ then the TELLER record would record this message into its
OVERRIDE fields as shown under:
Figure 277 Record of override of stopped cheque

Returned Cheques
If a cheque is to be returned, then, by entering ‘YES’ in the RETURN.CHEQUE field on

FUNDS.TRANSFER, it automatically returns a cheque, taking the payment from a return suspense
account as set in ACCOUNT.PARAMETER. The account that the transfer was originally to have been
from is then stored in DRAWN.ACCOUNT, which is found on both the FUNDS.TRANSFER and
STMT.ENTRY applications. The ranges in CHEQUE.REGISTER are maintained as normal.

Deposited Cheque Collection
The system handles the collection of deposited cheques; this is in addition to the normal method of
clearing cheques. The cheque clearing system takes cheques entered through TELLER,
FUNDS.TRANSFER or DATA.CAPTURE and creates a Cheque Collection Record for each cheque.
The cheque collection record can be processed individually or through CHEQUE.BATCH, that groups
batches of cheques together for processing. The processing caters for cheques deposited into the T24
bank that clear in a certain or uncertain number of days. For example foreign cheques may take an
uncertain number of days to clear, with this functionality T24 can deal with this. While the cheques are
waiting to be collected the funds are posted to a Suspense account. Upon the successful collection,
the funds are then credited to the customer. If the cheque is returned then funds in suspense to are
returned to a suspense account.
Set-up
The cheque collection functionality is triggered by TRANSACTION codes. New transaction codes are
created to indicate whether processing is required or not. After the new transaction codes have been
created they are input onto the Account parameter record. For every transaction created through
Funds Transfer, Data Capture or Teller, the system checks the account parameter record for the
transaction code. If the transaction code is not found on the account parameter record, the Cheque
Collection processing is by-passed.

Transaction codes
New transaction codes must be created as a means of identifying the transaction to be processed
through the cheque collection processing.
There are two methods of deciding which suspense account the funds go to for clearing and returns,
the suspense category is either defined on the Bank Sort Code record or on the Account Parameter
record with the transaction code. The transaction code decides where the funds should be posted,
there are a minimum of three transaction codes required on the Account Parameter record. A
transaction code must be created for the Collection of Cheques, the Clearing of Cheques and the
Return of Cheques. Multiple transaction codes can be set for each of the mentioned cheque actions.
The account parameter Account Parameter accepts multiple transaction codes as a unique
transaction code could be created for Funds Transfer, Data Capture and Teller.
For example a cheque is deposited using a TRANSACTION code that is on the Account Parameter
record, the transaction is then posted to the collection suspense account (as defined by the collection
category code on the ACCOUNT.PARAMETER record) and a Cheque collection record is created.
Figure 279 Cheque deposited sent for collection transaction code

Figure 281

Figure 282

Figure 283 Cheque transaction code

Figure 285 Cheque collection transaction code
The above example transaction codes will be used though the remainder of this manual. The
transaction codes are entered onto the ACCOUNT.PARAMETER record and also used by the Teller
Transaction codes.

Category Code
New CATEGORY codes will need to be created to enable the set up of the new suspense accounts.
These category codes specify which suspense account the funds should be held in. The category
codes can be defined on the ACCOUNT.PARAMETER record and/or the Bank sort code record, the
differences will be explained later on. There must be at least one category code for each transaction
code. The category codes must be between the range of 10000 and 19999, thus defining them as
internal accounts.
Figure 287 Cheque collection suspense category
Category Codes and Interest Adjustments
It is possible through fields on the ACCOUNT.PARAMETER application to configure the CATEGORY

codes used to book adjustments to the previous year and month, for all types of interest (Debit, Debit2,
Credit and Credit2). At correction time of a previous capitalisation the system will compare the
capitalisation date against the last FINANCIAL YEAR.END. In the COMPANY record and if the
correction date falls in the last year the P&L adjustment will be posted to the last year category, if not it
will be posted to this year. Debit interest adjustment categories must be in the range 51000 to 51999
and credit interest adjustment categories must be in the range 50000 to 50999.

Figure 289 Cheque categories entered onto the ACCOUNT.PARAMETER

Suspense Accounts
Internal suspense accounts need to be created for each CATEGORY code. These internal suspense
accounts are updated when the corresponding transaction codes are used in a transaction. As there
are three main category types required so too is there a need to create a minimum of three internal
Suspense accounts.
As the cheque progresses through the deposited Cheque Collection system, the funds move with it
through the internal suspense accounts until the cheque is cleared. If the cheque is returned then the
returned suspense account will contain the value of the returned cheque.
Figure 291 - Cheque Collection Suspense Account


Account Parameter
The ACCOUNT.PARAMETER record determines whether or not the deposited cheque collection
functionality should be invoked. If the ACCOUNT.PARAMETER record has the CHQ.DEP.TXN,
DEF.COLL.SUSP, CHQ.COLL.TXN, CHQ.RTN.TXN and the DEF.RTN.SUSP fields entered then the
deposited cheque collection functionality is invoked.
The system decides what processing to invoke by locating the transaction code in the transaction
code fields (CHQ.DEP.TXN, CHQ.COLL.TXN and CHQ.RTN.TXN) on the ACCOUNT.PARAMETER
record.
If the TRANSACTION code is found the system then assigns a CATEGORY code to the transaction.
The category code can come from two places; the BC.SORT.CODE record for the bank sort code
used in the transaction or from the ACCOUNT.PARAMETER record (transaction codes can have
associated category codes).
Figure 293 Linking transaction codes with suspense categories


Bank Sort code
Bank sort code records can be created with CATEGORY codes. The category codes are only used for
suspense deposited cheque collection transactions if the ACCOUNT.PARAMETER record is set. If the
ACCOUNT.PARAMETER record has been set, and a bank sort code is used by the transaction, the
system will firstly check the sort code record for a category code to suspend the funds. If there is no
CATEGORY code it will use the CATEGORY code from the ACCOUNT.PARAMETER record.
Having the CATEGORY codes on the BC.SORT.CODE records allows the funds to be posted to
individual suspense accounts for each bank.
Figure 295 Individual suspense accounts for a sortcode

FT LOCAL CLEARING and FT BC PARAMETER
The FT.BC.PARAMETER and the FT.LOCAL.CLEARING files go hand in hand. If you need to create
or modify the FT.BC.PARAMETER record then the FT.LOCAL.CLEARING record should also be
checked and/or updated. For further information on the FT.BC.PARAMETER file and the
FT.LOCAL.CLEARING file see the Funds Transfer and/or Local Clearing User Guides.

Cheque Collection
The cheque collection records are created through Funds Transfer, Data Capture and Teller. The
normal processing for these applications occur, however if the transaction code is found on the
account parameter record the system will also create a cheque collection record. In Teller the
TELLER.TRANSACTION code record contains the TRANSACTION code used in the contract, and in
FUNDS.TRANSFER the FT.TXN.TYPE.CONDITION code record contains the transaction code used
in the contract.
Figure 296 Incoming payment by cheque

In the above example the FT.TXN.TYPE.CONDITION record IC has a TRANSACTION code of 221
(Incoming Cheque Payment), therefore a cheque collection record has been created. For every Funds
Transfer, Data Capture and Teller transaction created the system searches through the list of
TRANSACTION codes on the ACCOUNT.PARAMETER trying to locate the TRANSACTION code of
the deal. The field on the ACCOUNT.PARAMETER where the TRANSACTION code is found
determines what processing is required for Cheque collection.
Normal account processing takes place on the transaction. In the example below you will see that the
USD Nostro account has been debited $543.00, while the internal suspense account has been
credited with the $543.00,$543.00; the customer account has not been credited. The internal
suspense account has been derived from the BC.SORT.CODE record 100000301123 which has a
Collection suspense CATEGORY of 14820.10400.

Figure 298 Debiting the Nostro

Figure 300 Crediting suspense
On the credit STMT.ENTRY record the CHQ.COLL.ID field indicates the Cheque Collection id -
Customer Account number.
The record is now available for processing through Cheque Collection. The Cheque collection record
shows the cheques status. Cheque Collection records are created with a status of Deposited, this
indicates a cheque has been entered into T24 and is waiting to be processed. Cheques can be

processed individually in Cheque collection or in batches through the Cheque Batch application (see
Cheque Batch section).
A Cheque can be Clearing, Cleared or Returned. The cheque collection CHQ.STATUS field indicates
what status the cheque is at. Cheques are usually sent for Clearing, and can come back either
returned or cleared. The Cheque collection record then has the CHQ.STATUS field changed to the
appropriate status.
The cheque collection record is processed through changing the CHQ.STATUS to the required status.
The status will be changed to clearing,, which means the cheque has been sent to the appropriate
bank for action. The reply from the bank will determine which status is to be entered next, if the
cheque is cleared the cheque collection record CHQ.STATUS field is changed to cleared.
Figure 302 - Cleared Cheque
The cheque collection record with a CHQ.STATUS of cleared will create the following accounting
entries. The accounting entries will credit the customer account and debit the internal suspense
account completing the transaction. Note that no accounting entries are generated when the cheque
status changes from deposited to clearing.

Below, are all the entries which are raised by a cleared cheque with charges when processed through
the Cheque Collection application.
Figure 304 - Accounting entries for cleared cheque
There are five entries raised by the clearing of a CHEQUE.COLLECTION record, the crediting of the
customer and the debiting of the suspense account are standard. There is one entry for charges and
the other two entries come from a linked FT.CHARGE.CODE.

Figure 306 - Debiting suspense

Figure 308 - Crediting customer

Cheques can be bounced/returned by the other bank and this results in the funds being transferred
from the internal cheque collection suspense account to the returned cheque collection suspense
account. The returned suspense account can be derived from the either the BC.SORT.CODE file or
the ACCOUNT.PARAMETER file.
Figure 311 - Returned cheque
Along with the normal accounting entries for the Funds Transfer there is the debiting of the cheque
collection suspense account and the crediting of the returned cheque collection suspense account.
Figure 312 - Accounting entries for returned cheque


Cheque Batch
CHEQUE.BATCH is the application that provides a method of clearing multiple deposited cheques.
Cheques can be of varying currencies and denominations with the validation ensuring the entered
total of each currency matches the calculated total for the batch. The cheques are then returned by
the external banks and are either cleared or returned. The entire batch can be updated, or individual
items can be updated.
CHEQUE.COLLECTION records can only be added to the CHEQUE.BATCH record if they have a
status of Deposited, which will be changed to Clearing, as they are entered into the CHEQUE.BATCH
record.
The CHEQUE.COLLECTION record can be added in either by entering the CHEQUE.COLLECTION

id's individually into the CHEQUE.BATCH record or they can be entered in a group by selecting a
group from an ENQUIRY and then dropping the group into the CHQ.COLL.ID field. The later method
of populating the CHEQUE.BATCH record automatically opens a new multi-value for each item in the
group. This can be done using the standard Windows selection methods. Hold down the CTRL key,
highlight the selected items with the mouse pointer, drag the selection to the CHQ.COLL.ID field then
drop the selection into the field.
Figure 314 - Creating a CHEQUE.BATCH

The five items from the enquiry that are highlighted are dragged to the CHQ.COLL.ID field, which
expands. The cheque batch record will look as below:
Figure 316 - Populated CHEQUE.BATCH
The CHEQUE.BATCH application will update the status of all the Cheque collection records on the
batch automatically. The record will stay with a status of clearing until a cheque or all the cheques
have been either cleared or returned.

Figure 318 - Cheque in clearing
If a CHEQUE.COLLECTION record is part of a CHEQUE.BATCH the status of the record can only be
updated through the CHEQUE.BATCH application. In CHEQUE.BATCH it is possible to update the
status of individual CHEQUE.COLLECTION records or to update the whole batch by changing the
OVERALL.STATUS field to the desired status. Changing the overall status field will update every
CHEQUE.COLLECTION record that currently has a status of clearing with the status entered in the
OVERALL.STATUS field.
In the below example the cheque for USD 2000.00 is returned, the individual status of the
CHEQUE.COLLECTION record has been updated leaving the status of all other
CHEQUE.COLLECTION records unchanged. The returned cheque funds will be posted to the return
Cheque Suspense account.

Figure 320 - Returned cheque in CHEQUE.BATCH
If the remaining cheques come back cleared then the OVERALL.STATUS can be updated to cleared,
this will populate all remaining status fields that have a status of clearing to Cleared.

Figure 322 - Mixed status cheques in a batch
All CHEQUE.COLLECTION records on this CHEQUE.BATCH record that have a status of clearing
have been set to cleared. Below is the CHEQUE.COLLECTION record that has been returned noting
that this record has not been updated since the status had been set to returned.

Figure 324 - Cleared cheque from batch

Figure 326

Figure 327 - Returned cheque from batch
CHEQUES RE-BATCH
An application called CHEQUE.CHANGE has been introduced for the purpose of selecting cheque
collection records or cheque batches and group them for further processing.
If CHEQUE.BATCH is selected as APP.ID and no further selections are made, all the open cheque
batches will be grouped together. This will be useful at a Service Branch of the bank to combine the
batches received from various branches and present them to Clearing House. The regrouped new
batch ID will be displayed as a no input field in BATCH.ID.
Grouping of Cheque Batches can be done using the fields, SELECTION.FIELD, OPERAND and DATA
DATA. On Verify mode, the process like re-batch will be done.
CHEQUE COLLECTION ACCOUNTING
Cheque Collection Accounting
A new table called STOCK.PARAMETER is created with a field named DEF.COLL.SUSP. If the
credit side transaction code of the TELLER.TRANSACTION relating to Clearing is defined in this table

and the DEF.COLL.SUSP field is left blank, then the credit of Cheque Collection record will go directly
to the customer account. Otherwise it will follow the usual path defined in ACCOUNT.PARAMETER.
The same code will not be permitted both in STOCK.PARAMETER and ACCOUNT.PARAMETER.
Cheque Collection records are created by the system for the full amount, without deducting charges. A
field named DEFER.CHARGE is introduced in TELLER.TRANSACTION, if the credit side transaction
code matches the transaction code defined in ACCOUNT.PARAMETER or STOCK.PARAMETER
under CHQ.DEP.TXN. If YES is defined under DEFER.CHARGE, then the charges defined at
TELLER level will be carried over to Cheque Collection record and will be processed at the time of
regularising the credit as CLEARED or RETURNED. Otherwise the charges will be collected at the
Teller entry level itself.
Bulk Accrual of Interest and Charges
Introduction
Interest and charges for accounts are accrued either on a DAILY or MONTHLY basis, the default
frequency being monthly. The frequency is normally defined in the ACCOUNT.ACCRUAL application.
Daily accruals may be requested for all accounts, all foreign or all local, or by product category.
Whenever an ACCOUNT is capitalised (defined by the frequency in GROUP.CAPITALISATION or

ACCT.CAPTALISATION) the accrual calculation is repeated to ensure that the accrued interest in P&L
is accurate and the accrual balance in the CRB is reversed.
When a daily (or other period) accrual is required for the accounts, however the accrual entries do not
need to be raised for each individual account, the level of currency, department and product category
or group should be sufficient. Accrual entries should be raised as a single P&L (CATEG.ENTRY) and
special (RE.CONSOL.SPEC.ENTRY) for each grouping.
When an account is capitalised, or a detailed accrual is required, the system will ensure that the group
accrual figure for as given account is reversed to avoid reporting the same figure twice.
Accounts to be accrued in bulk
This bulk accrual facility is created to allow these daily (or other) periodic accruals and postings to be
performed at a high level. Where bulk accrual takes place the accrual calculation is simplified and is
simply on a daily accrual figure. The daily accrual figure can be revised when an individual account
moves.

Setting Group Accrual Parameter
The accounts to be accrued in bulk are identified by the GROUP.ACCRUAL.PARAM application.

See the screenshot below.
Figure 329 - Bulk accrual for specified categories
This identifies which product categories are to be accrued, the frequency of the accrual and
recalculation of daily accrual figures.
The Close of Business programs will compare any duplicate / overlapping settings made in this
parameter file and the ACCOUNT.ACCRUAL file and will give precedence to the group accrual
functionality.
Refer to the Help-text for more information.
A rebuild of the group accrual files is necessary when a GROUP.ACCRUAL.PARAM record is

input and whenever the parameter settings for group accruals have been changed. Refer to the
'Rebuilding Group Accrual' section of this user guide.

Rebuilding Group Accrual
A rebuild of the group accrual files is necessary when a GROUP.ACCRUAL.PARAM record is input
and whenever the parameter settings for group accruals have been changed.
The Group Accrual files can be rebuilt on-line or as part of the batch processing.
The application REBUILD.GROUP.ACCRUAL is used to drive the rebuilding of Group Accrual. The
figure below shows the accrual of all current accounts.
Figure 331 - Rebuild of group accruals
Note: REBUILD.GROUP.ACCRUAL is run in Verify mode for an on-line rebuild.

Calculation of Daily Accrual Figures
Each account subject to group accrual will store a daily average accrual figure for each type of interest
and/or charge defined. This figure will be re-calculated either when an account moves or when a
scheduled recalculation is run. The figure is calculated by projecting the interest forwards to the next
capitalisation date (based on the current account balances). The projected interest / charge amount is
then divided by the period of the calculation to give an average daily amount. The daily amount will be
stored in the application GROUP.ACCRUAL.DETAIL (See figures screenshot below); amounts will be
held by P&L category.
Figure 333 - GROUP.ACCRUAL.DETAIL

Posting of Group Accrual
Posting of Group Accrual
The GROUP.ACCRUAL.DETAIL application will be consolidated periodically by currency, product

category and department, the department. The total balances will be held in the
GROUP.ACCRUAL.BALANCES application (See figure below). The periodic accrual process will post
the difference between the previous total and the current accrual total.
Figure 335 - GROUP.ACCRUAL.BALANCES

TSA.SERVICE
The TSA.SERVICE record BNK/GROUP.ACCRUAL.ONLINE can be activated to run on line, and will
run indefinitely until stopped by the user.
Figure 337 TSA.SERVICE
The function of this agent is to reduce Close of Business overhead processing time for any intra day
updates to the group accrual records.
The associated GROUP.ACCRUAL.DETAIL records pertaining to this account will be rebuilt online.

Interest Compensation Accounts Hierarchy (ICA)
Introduction
Accounts can be linked into a hierarchical structure of individual groups. Each group consists of a
main account to which other (sub accounts) can be linked. A main account in one group can be a sub
account in another higher-level group. At any one time an account can therefore be a member of a
maximum of two ICA groups.
There is no limit imposed on the number of sub accounts in an individual group and no limit imposed
on the number of levels of groups in a hierarchy.
Accounts within a group and therefore within the same hierarchy must be of the same currency or of
the same fixed currency group, e.g. members of the Euro group.
Hierarchies are constructed for the purpose of distributing the difference between interest earned by
the group as a whole, based on the interest conditions pertaining to the main account of the group,
and the total of the interest earned by the individual group members (including the main account).
Interest distributions are split into the four interest types available in T24, i.e. DR, DR2, CR and CR2.
An ICA account can receive three types of interest posting: -
• Normal Interest as takes place for a standard T24 account.

• ICA Interest due as the main account of an ICA group.
• ICA Interest due as the sub account of an ICA group.
NB. Tax and charges are not applicable to ICA hierarchy interest calculation and postings; their
purpose is for the distribution of interest only.
NB. ICA group interest is not accrued it is calculated and posted at the time the main account in a
group is capitalised.
The difference between interest earned by the group as a whole and the total of the interest earned by
the group members can be distributed to the sub accounts of the group using two different methods: -
Ratio: where a straight percentage of the group interest is allocated to a sub account.
! Group Difference * Ratio / 100
! Interest: where the proportion of interest earned by the sub account indicates the proportion
of group difference allocated to the sub account.
! Group Difference * (Interest earned by sub account / Interest earned by all accounts).

In both cases the remainder of any unallocated interest is allocated to the main account.
Using the Ratio method the default scenario will be to allocate zero ICA interest to the sub accounts
and therefore all interest goes to the main account.
If when a main account is capitalised a sub account has subsequently been closed, then any ICA
interest due to the sub account will be allocated to the main account. If the main account has been
closed then the interest due to the main account will be allocated to a suspense account.
NB. Account Class records must be created for ICA interest, they should have the following keys: -
• ICASUSPCR for credit interest postings

• ICASUSPDR for debit interest postings
If desired the category codes can be set to be the same values as for normal interest i.e.
The account class records SUSPCREDIT and SUSPDEBIT.
The following example describes a simple ICA hierarchy of one top-level group with two sub groups.

Figure 338 - Example of ICA hierarchy
The example shows a small ICA hierarchy made up of three actual groups, ICA1 the top-level group
and ICA2 and ICA3 two sub level groups linked to the top-level group.
Each group has three accounts, one main account and two sub accounts.
Two of the accounts AC2 and AC3 are both main accounts of their respective groups and sub
accounts of the top-level group. The top account is AC1.
The values shown are as follows; -follows:
• “Balance” indicates the account and group balances.

• “Rate” indicates the account and group rates.
• “Normal int” indicates the interest at account level and the total interest at group level. Note that
for group level normal interest the actual total will include group level interest if the sub account
is also a main account, i.e. the normal interest for group 1 is calculated as 3 (interest for AC1) +
6 (group interest for ICA2) + 6 (group interest for ICA3).

• Group interest is calculated using the group balance and the interest rate applicable to the main
account.
• Group difference is calculated as group interest - normal interest.
N.B. the formula used to calculate interest in this example is simplified to be a straight percentage of
the balance.
Interest distribution is shown using the ratio method, with values shown on the sub dist% field.
The three possible types of interest posting are shown i.e.:
• Normal Interest.
• Sub account level group distribution interest.
• Main account level group distribution interest.
N.B. Group Interest will be calculated at the capitalisation dates, it will not be accrued during the
capitalisation period.
Account membership of ICA groups can change: -
• An account can move from one group to another.

• If the account to move is a main account, then all sub accounts and groups linked to it at a lower
level will move with it.
• A link can be back valued to any time within the current interest capitalisation period.
• An account cannot be linked to another account, which has been linked to it at any time, i.e.
circular links are not allowed.
• It is possible to move an account and any accounts linked to it at a lower level from one hierarchy
to another.
• The time that a sub account was a member of a group is taken into consideration when interest is
calculated; i.e. only the interest earned during the actual period of membership is used in ICA
calculations. If the sub account is also a main account then this also applies to the interest earned
by the sub group.
Generally the capitalisation dates of sub accounts should coincide with those of the main account. If
capitalisation is monthly then the day of the month should be the same for main and sub account. The
capitalisation frequency of the sub account must not be less than that of the main account, e.g. a sub
account can capitalise monthly and a main account quarterly not vice versa. An override will be
generated if this is not the case.
N.B For the Interest compensation to work properly, interest capitalisation frequency
should not be less than monthly.

Special ACCT.ACTIVITY records are created to store ICA information related to account balances, for
each group and for situations where an account or group of accounts were only partial members of an
ICA group.
The key to these records is in the format MAIN.ACCOUNT*SUB.ACCOUNT-YYYYMM. If the data

relates to a group then the sub account part of the key will be left blank.
In the same manner special STMT.ACCT.XX and CORR.ACCT.XX records will be created to store the
interest calculation results for ICA groups, where XX indicates DR, DR2, CR and CR2.
Correction processing takes place in the same manner and at the same time as standard T24 interest
correction processing.
The actual interest postings of ICA interest will be stored on the standard T24 STMT.ACCT.XX
records.
Interest postings will be separated into the different types of interest.

Setting up an ICA Hierarchy
ICA.HIERARCHY.PARAMETER
Figure 340 - Category and transaction codes for ICA
This record must be set up first, before any input can be made to build a hierarchy.
It contains category and transaction codes for all the possible types of ICA interest postings.
If on first input the record is committed it will default the existing hard coded category and transaction
codes used to post interest in T24.
A second input can be made to modify the relevant codes, which can be used to identify ICA postings.
For example it may be decided to keep the existing category codes but to use different transaction
codes for ICA interest.


ICA.HIERARCHY
Figure 342 Define the top account of the hierarchy
Figure 344 - Define the top account of the hierarchy
Before an ICA hierarchy can be set up, a record to describe the hierarchy and to define the main
account of the top-level group of the hierarchy must be defined.

Defining the Top Account
Figure 345 - ICA fields on the top account
A hierarchy should be set up in a logical manner starting from the top account and progressing down
through the hierarchy level by level.
The top account in the hierarchy is defined by linking it to itself, indicated by the field
ICA.MAIN.ACCOUNT.
The field ICA.MAIN.ACCT.IND is set to YES indicating that this account is the main account of an
ICA group.
ICA.DISTRIB.TYPE indicates that the distribution method for which this group is the main account is
to be the RATIO method.
ICA.POST.INTEREST is applicable to all ICA accounts and indicates the type of interest posting
applicable to all interest types for ICA accounts. There are three types of interest posting: -

• YES – interest posting takes place as normal.

• INFO – interest is calculated and interest statement files are updated but no interest is posted.
• OFF – No interest is calculated and interest statement files are not updated so no interest
is posted.
NB. The OFF option should not be selected for a main account as this has the effect of turning off ICA
interest postings for the whole group.
ICA.MAIN.RATIO indicates the total percentage of ICA interest, which has been allocated to sub
accounts for which this account is the main account when the ratio method interest distribution has
been defined.

Defining a sub account which is also a main account
Table 2 - An account, which is both a sub and main account
In this example the account has been linked to a higher level account but has itself been defined as a
main account, i.e. ICA.MAIN.ACCT.IND = YES.
The fields ICA.MAIN.ACCT and ICA.MAIN.ACCT.DATE indicate that the historical links for this
account.

Defining a stand alone sub account
Figure 348 - Sub account
This example shows a sub account, which does not have any other accounts linked to it, i.e.
MAIN.ACCT.IND is null. If it is required to link sub accounts to this account then the
MAIN.ACCT.IND field should be set to YES before linking other accounts to it.
NB. In this example it can be seen that this account was linked to the main account 18961 from the
first of1st May, removed on the fifth of may5th May and then re linked on the 7thof August.
Interest is taken into account for ICA purposes only for the periods that an account was a member of
an ICA group.

Defining a new LINK
Figure 350 - Defining a new ICA link
In this example it has been decided to change the link for the above account from 18953 to 18961,
and for the link to be effective from the first of January.
If this account were itself a main account then changing the link would effectively change the links of
all accounts linked to this account.
Links cannot be back-valued past the last capitalisation date of the account.

ICA.GROUP.DETAIL
Figure 352 - ICA.GROUP.DETAIL
Each ICA group will have an associated ICA.GROUP.DETAIL record, which contains all pertinent data
for the group, and is updated automatically. The key to each record is the main account number of the
group.
It contains historical data related to the level that the group resided in the hierarchy, and to the
membership periods of sub accounts.
It is important to know the hierarchy level of a group, in particular the maximum number of levels that a
group has been from the top of a hierarchy. When account balances are combined for ICA groups into
special ACCT.ACTIVITY records those groups at the bottom of the hierarchy must be processed first;
this is because higher-level groups require the combined balances of lower level groups in order to
calculate interest. This information is stored in the MAX.PROC.LEVEL field.

Details of the group interest calculations relating to the latest ICA capitalisation are also stored here.
An application ICA.GROUP.HISTORY contains data relating to past interest capitalisation. The key is
appended with the capitalisation date.

ICA.GROUP.DISTRIBUTION
Figure 354 - ICA.GROUP.DISTRIBUTION
This file is updated whenever an ICA main account is capitalised, and is used to drive the ICA interest
capitalisation processing: -
• MAX.PROC.LEVEL indicates the process level of the group, those furthest from the top of a
hierarchy are processed first.
• INTEREST.CALC indicates which types of interest were capitalised characters 2 to 4 represent
CR, CR2, DR and DR2 accordingly.
• START.DATE.XX indicates the beginning of the respective interest calculation period.
• END.DATE is the capitalisation date.
• MAIN.ACCTY.KEY stores the ACCT.ACTIVITY keys used to store ICA group balances.
• PARTIAL.ACCOUNT stores details of all sub accounts which were not members for the full
capitalisation period.
• PART.ACCTYS stores the ACCT.ACTIVITY keys relating to the balances for the partial
membership period.

• PART.STMT.XX does the same for the STMT.ACCT.XX records.

ICA Group account activity record
Figure 356 - ACCT.ACTIVITY record for top account
Only the relevant data for ICA interest calculations is stored i.e. the day number of the month and the
balance on that date. This example shows the combined balances for the top-level group.

STMT.ACCT.CR record
STMT.ACCT.CR Record
Figure 358 - Record of credit interest for top account
Details of ICA interest postings are stored in the standard T24 STMT.ACCT.XX record. This example
shows the CR type interest posting for account the main account of an ICA group. If this account were
also a sub account of a higher-level group the details of any interest due, as a sub account of the
higher-level group would also be shown.

GWHT (GERMAN WITHHOLDING TAX)GWHT (German Withholding Tax)
When a Bank has all the customer information in place they will need to set-up a new TAX.TYPE,
APPL.GEN.CONDITION, TAX, TAX.GEN.CONDITION and a TAX.TYPE.CONDITION for the
customers that they wish to be considered for GWHT processing. This will basically be a German
resident as defined on the CUSTOMER file. The specific TAX.TYPE called GWHT will indicate that a
customer will be liable for German Tax. The following screen shots and descriptions will show
examples of how to set-up the processing tables: -.
TAX.TYPE: -
Figure 360 TAX.TYPE:-

Figure 361 TAX.TYPE
This application allows definition of the types of TAX, which may be calculated within T24. Conditions
for applying this tax for a given set of customer conditions maybe defined in the next set of
applications: TAX.TYPE.CONDITION and TAX.GEN.CONDITION.
APPL.GEN.CONDITION: -
Figure 363

APPL.GEN.CONDITION:-
Figure 364 - APPL.GEN.CONDITION
This application can be used to allocate the group you have defined for GWHT. The above description
shows that for Money Markets Conditions, any deal entered under CONTRACT.GRP MMCAT which is
equal to category 21012 (MM Deposits.) is liable for GWHT if that CONTRACT.GRP is set up in
TAX.TYPE.CONDITION,TAX.TYPE.CONDITION. This will be shown in further diagrams. The
DECISION fields can be multi-valued to add in new conditions for that category, e.g. for GWHT
deposits placed at 1.00 % or less are not liable for GWHT, as shown in the shot below: -screenshot
below:

Figure 366 - Multi-valued APPL.GEN.CONDITION
The above screenshot can also be input under L&D categories.
TAX
The set up of the TAX for GWHT is similar to the existing functionality but 3 new fields have been
entered:-
1. LINK.TAX. This new field will contain a link to another existing tax record on this file and will form
the basis of the ‘TAX-ON-TAX’ processing. The entry here must be a valid Tax record and if that
has a link tax already in place this must be checked for duplication.
1. LINK.TAX. This new field will contain a link to another existing tax record on this file and will
form the basis of the ‘TAX-ON-TAX’ processing. The entry here must be a valid Tax record and
if that has a link tax already in place this must be checked for duplication.
TAX.BASE this
2. new field will contain either Tax or Event. If tax is chosen this shows that the above id is to be
calculated as a tax on tax. If Event is chosen it will indicate that the above tax is linked to an event.
2. TAX.BASE. This new field will contain either Tax or Event. If tax is chosen this shows that the
above id is to be calculated as a tax on tax. If Event is chosen it will indicate that the above tax
is linked to an event.

3. UPDATE.POOL.SEQ. This new field has been introduced for the updating of the customer’s record
via a Kest type pool. (Pool.1) Any entries passed over Pool.1 are Kest liable so therefore will
update the CUST.TAX.ALLOWANCE accordingly. If left blank then no Pools will be updated.
3. UPDATE.POOL.SEQ. This new field has been introduced for the updating of the customer’s
record via a Kest type pool. (Pool.1) Any entries passed over Pool.1 are Kest liable so therefore
will update the CUST.TAX.ALLOWANCE accordingly. If left blank then no Pools will be
updated.
Shown below is the TAX file for ZEST with the link shown to SOLI.
Figure 368 - TAX record for ZEST
The screen shot below will show the ‘LINK’ that the ZEST tax has with the SOLI. As you can see from
field LINK.TAX above, it is linked to another TAX record.
LINK.TAX with another TAX present will use the ‘TAX-ON-TAX’ scenario.

Figure 369
Figure 370
Figure 371 - TAX record for SOLI
Each Tax has a different CATEGORY for processing. This allowance allows for the different amounts
of tax to be processed on an individual basis, per percentage of Tax. The Dr and Cr codes can remain
the same for bulk processing.

TAX.GEN.CONDITION:-
The set-up for TAX.GEN.CONDITION will determine who you want the process GWHT to affect. The
set up must contain the TAX.TYPE you set up originally and can be split to show the
Residency/Sector and Nationality of GWHT recipients.
The set-up here will also show those customers who are liable for GWHT but are also exempt to a
certain percentage of the Tax, e.g. Non-profit making organisations. These are also added here but
can have Exemption Certificates against them. This will be explained further on.
Below is the set-up for Customers that are liable for GWHT via standard T24 processing in
TAX.GEN.CONDITION:-TAX.GEN.CONDITION.
Figure 373 - TAX.GEN.CONDITION
The next shot shows that any customers in 1000 or 1600 sector that are also resident in Germany and
have German Nationality are liable for GWHT. This can be changed if customers are not residents of
Germany and therefore not liable for GWHT.

EXEMPTION
Exemption
The next shot shows the Customer exemption. This applies to Non-profit making Organisations, e.g.
Churches, Sports Funds who can claim Part/Full exemption from GWHT. These are named ‘NV’
certificates and carry a wide range of percentage reductions.
Figure 375 - EXEMPTION
The EXEMPTION shown here will bear a 50 % reduction on Zest processing if added to a
CUST.TAX.ALLOWANCE at input Stage.
This can be transferred to CUST.TAX.ALLOWANCE to give a percentage reduction in Zest GWHT

processing. The shot below shows a customer with NV01 certification that gives him Exemption for 1
year at 50% of the Zest percentage from 01/03/01 until 28/02/02.

Figure 377 - CUST.TAX.ALLOWANCE
TAX.TYPE.CONDITION
The TAX.TYPE.CONDTION table will govern which contract groups will incur GWHT.
Included with the TAX.TYPE.CONDITION is the tax liable for those chosen. As per the set up in
APPL.GEN.CONDITION, the contract groups set in here along with the Tax set up will form the main
GHWT functionality.

Figure 379 - TAX.TYPE.CONDITION
CUST.TAX.ALLOWANCE
The set-up of CUST.TAX.ALLOWANCE is based on all the above functionalities that have been set up
previous to this. It is individually based but there is an option to Merge/De-Merge customers based on
circumstances such as Marriage, Divorce, and Death.
This allows individual customers to increase their single allowance to a joint allowance. They can also
spread their allowance amongst different institutions depending on their account structure. But, as any
taxation, it is centrally reported, so therefore it is up to the individual/s to maintain their correct Tax
returns or be liable for penalties.
The set-up involves the T24 CUSTOMER number plus the current tax year (Which(which is added
automatically at process). For allowance purposes, the Customer has to request what amount he/she
wishes to use within the institution. Additionally, there is an ALLOWANCE.MOVEMENT amount which
lets the customer Increase/Decrease their current ALLOWANCE if need be by the process of a + or – in
front of the amount. This is governed by the MAX.ALLOWANCE amount,, which cannot be broken at
any time.
Below shows the set-up of an individual CUST.TAX.ALLOWANCE, which has a MAX.ALLOWANCE of

Dem 3100 and an ALLOWANCE.MOVEMENT of Dem 3100. This means the customer in question has a
normal allowance of Dem 3100 but can adjust it up to Dem 3100 at any time, though this is the
maximum he/she can go up to.

Figure 170.381 - Amending the CUST.TAX.ALLOWANCE

Figure 168
CUST.TAX.ENTITY
The CUST.TAX.ENTITY application allows the institution to Merge/De-merge customers to give them
1one single allowance for a joint couple (MERGE Process). This process happens (MERGE) if
customers are joined in Marriage.
It is up to the individual customers to tell the institution what allowance they wish to set (as per the
single CUST.TAX.ALLOWANCE) for the joint application. The rules of MAX.ALLOWANCE and
ALLOWANCE.MOVEMENT still apply for a joint application.
If one member of the party is does not hold an account with the institution, an account has to be set-
up to complete the merge. This process can only work for individual customers and not for any other
companies.
Once customers are merged you can amend their CUST.TAX.ALLOWANCE to a new amount if they
wish to Increase/Decrease their Allowance, however this cannot break their original MAX.ALLOWANCE.
The opposite of this is the De-Merge process. This happens if the Customers divorce or in the
circumstance of death. Again, it is up to the Individual/s to advise their Bank regarding this.
Once the De-merge process is complete you will need to set up a new CUST.TAX.ALLOWANCE for
the new customers again only if they wish to change their allowances.

On the next page you can see the Merge/De-merge process in the way of screen shoots, including the
CUST.TAX .ENTITY shots, including the CUST.TAX.ENTITY showing this.
The first two screen shots show individual customers with ‘SINGLE’ allowances before the ‘MERGE’
process.
Figure 382 - Single allowance 1
Figure 384 - Single allowance 2

Figure 170
The next will show the process of Merge and De-merge via CUST.TAX.ENTITY. Once set up
CUST.TAX.ENTITY will still keep a record of the ‘Individual’ allowances, but that is for the ‘De-merge’
option.
Figure 386 - Merged allowance on CUST.TAX.ENTITY
As stated, in the case of divorce or death the process of ‘De-merge’ will take place. This reverts the
customers back to their single status and a new allowance (if necessary) must be input. Depending on
the split of allowance, it must be checked against any outstanding and settled trades that have and will
pass through their accounts. This is done at customer level and they must advise their institution what
balance they have left (per customer) after they have decided on what allowance they have left.

Figure 388 De-merging
ACCOUNTING SET-UP
Accounting Set-up
For T24 to post deducted tax amounts to CUST.TAX.ALLOWANCE the accounting side must be set
up correctly. For LC, MM and Interest and Charges the Transaction Codes are hard coded and
therefore must by defined for the individual deal type, otherwise T24 will calculate GHWT but not post
it to the Customer GWHT framework.
The accounting set up involves the input of a new field in the TRANSACTION application. The
UPDATE.INTEREST.POOLS field, when set to ‘YES’ will (as it states) update the Interest Pools of
POOL.1 (individual customer taxation) and pass accounting entries to show this. If left blank normal
accounting is still performed (Default is ‘NO’).
As stated before, the Transaction Codes for T24 Accounting are hard coded per module so for each
type the UPDATE.INTEREST.POOLS must be set to ‘YES’.
The hard coded Transaction codes are found in the SYSTEM.RECORD application of T24 and hold all
the Transactions codes for the different Modules.
The current Codes are as follows for INTEREST &and CHARGES

INTEREST & CHARGES:-and CHARGES: 381 and 382
Depending on what LD and MM deals you are setting up in your APPL.GEN.CONDITION you will
have to amend the TRANSACTION codes accordingly.
INCOME.TAX.CALC
This new field has been added to the MM and LD portion of GWHT and enables a customer to
indicate how the interest tax is to be calculated for the deposit.
1. FULL or NULL
The full interest will be calculated and deducted from the interest, i.e. no tax allowance nor exemption
will be taken into account.
2. REDUCED
The interest will be offset by any tax allowance or exemption. If the resultant is greater than 0 then it
will be used as the base to calculate the interest tax, which will then be deducted from the interest.
Otherwise, there will be no interest tax. The tax allowance of the customer will be REDUCED in both
cases.
3. ZERO
This deposit will be free of interest tax.
VALIDATION RULES
Valid rules are:
. NULL
. FULL
. REDUCED
. ZERO
DEFAULT IS ‘NULL’

Figure 389 - Tax calculation on MM

Account Tax Computation Joint Holder wise

There may be accounts in a Bank where each joint holder falls into different tax slabs based on their
RESIDENCE, NATIONALITY, SECTOR, etc. T24 allows for computation of tax on ACCOUNT
interest based on the individual tax status of each joint holder.
Tax can be calculated JOINT.HOLDER wise on ACCOUNT interest by adding a sample routine
TAX.LOCAL.RTN in field no.34 CALC.ROUTINE in application TAX.
When tax joint holder wise is to be computed, a valid TAX.TYPE.CONDITION record has to be
specified in ACCOUNT.CREDIT.INTEREST / ACCOUNT.DEBIT.INTEREST /
GROUP.DEBIT.INTEREST / GROUP.CREDIT.INTEREST in the field TAX.KEY as shown in the
below screen shot.
Figure 391 - ACCOUNT.CREDIT.INTEREST
As shown in the above screen shot, the field TAX.KEY has to be input with the tax type and not the
tax key for computing tax joint holder wise for an account.
From the tax type specified for the account, for the tax key applicable for the main customer based on
the tax type specified in CUSTOMER.CHARGE table, the local routine must be input in application
TAX in the field CALC.ROUTINE.
When a customer record is created based on the RESIDENCE, NATIONALITY, SECTOR, etc
TAX.GEN.CONDITION is validated for the tax conditions applicable for the customer and the same is
updated in table CUSTOMER.CHARGE. When the tax type is specified on the account interest, it
checks for a valid TAX.TYPE and a TAX.ACT.GROUP in CUSTOMER.CHARGE and applies the
TAX rate for the group in field CUST.TAX.GRP of TAX.TYPE.CONDITION for each joint holder.
Screen shots of TAX, TAX.TYPE.CONDITION, TAX.GEN.CONDITION, CUSTOMER.CHARGE.

Figure 392 TAX.GEN.CONDITION
Figure 393 - CUSTOMER.CHARGE
Figure 394 - TAX.TYPE.CONDITION

Figure 395 - TAX
TAX.LOCAL.RTN
The routine is to be input for the Tax key applicable to the main customer in the account. Tax for the
account will be computed JOINT.HOLDER wise and the total of the individual TAX will be computed.
Credit Interest or Debit Interest on the ACCOUNT, is divided equally based on the number of holders
and then Tax is calculated.
For example, if there is a main CUSTOMER.ID and a JOINT.HOLDER in an ACCOUNT with TAX
rates as 10% for the main CUSTOMER.ID and 20% for the JOINT.HOLDER based on their status,
and if the interest earned is 100USD, the interest amount will be equally divided as 50USD to each
JOINT.HOLDER and the tax computed would be 5USD for main CUSTOMER.ID and 10USD for the
JOINT.HOLDER, so the total tax for the ACCOUNT would be 15USD.
The individual tax amounts JOINT.HOLDER wise can be viewed through INT.MOVEMENT and
through the table TAX.CAP.LOCAL.INFO. To enable update of INT.MOVEMENT the field
INT.MVMT.UPDATE must be set to “Y” flag in application ACCOUNT.PARAMETER and also a valid
Interest and Charge application ID must be specified in field SYSTEM.ID in application
INT.MOVEMENT.PARAM.
Screen shots of ACCOUNT.PARAMETER, INT.MOVEMENT.PARAM, INT.MOVEMENT and

TAX.CAP.LOCAL.INFO.

Figure 396 - ACCOUNT.PARAMETER
Field INT.MVMT.UPDATE is set to flag “Y” in ACCOUNT.PARAMETER as shown in the above

screen shot.
Figure 397 - INT.MOVEMENT.PARAM
Field SYSTEM.ID in application INT.MOVEMENT.PARAM has to be set to the Interest and Charges
application ID as shown in the above screen shot.
Figure 398 - TAX.CAP.LOCAL.INFO

TAX.CAP.LOCAL.INFO displays the tax amount for the joint account customer wise as shown in the
screen shot above.
Figure 399 - INT.MOVEMENT
INT.MOVEMENT as displayed in the above screen shot will show the tax amount for the joint account
customer wise along with other details like total interest amount.
HIGH VOLUME ACCOUNT PERFORMANCE

Introduction to high volume account performance
In response to the performance issues related to high volume of entries passed over the same
account and for a better through-put of high volume of transactions, sub account processing and
consolidation of entries allows :
• The ability to automatically distribute transactions across linked sub-accounts without need to
modify the main settlement account specified on the transaction.
• The ability to automatically create sub-accounts as required
• The ability to create net statement and category entries automatically and so reduce high
volumes of entries
• The ability to keep the detail behind net entries for detailed investigation
• Detailed entries can be archived frequently to reduce the size of the database
Account with High Volumes

Accounts with these high volumes of entries tend to be accounts used for internal purposes
• Nostro Accounts
• Clearing Accounts
• Internal accounts used for purposes such as inter-company accounting, reserve accrual, off
balance revaluation, suspense processing and general ‘wash’ accounts
In general these types of account have no requirement for balance checking and interest calculations.

SUB-ACCOUNT PROCESSING
The ACCOUNT application allows the entries for an account to be distributed automatically across
sub-accounts. The system will automatically allocate an entry to a linked sub-account within the
accounting sub-system processing. This will ensure that locking contention is minimised.
Sub-accounts linked to the main account are held in the cross-reference table AC.SUB.ACCOUNT.
Setting up a High Volume Account

If an account is defined as a high volume account record, to allow the sub-account processing a value
between 1 and 99 must be defined under the field MAX.SUB.ACCOUNT, which will define the
maximum number of sub-accounts that the high volume account can hold. If no value is specified the
account will be processed as normal.
In addition to this, a record should be created in AC.AUTO.ACCOUNT under the account category to
define how the system will automatically create the sub-account.
Figure 400 SETTING UP AN ACCOUNT AS A HIGH VOLUME ACCOUNT
Whenever a transaction(both real and forward accounting transaction) hits a high volume account, the
system will allocate the sub-account from the AC.SUB.ACCOUNT table on a random basis using the
maximum number of sub-accounts as the maximum value.
The STMT.ENTRY record will be used to store the original account number under the field
MASTER.ACCOUNT.

Automatic Creation of Sub Accounts

When the system attempts to allocate a sub-account number based on the maximum number of sub-
accounts, and finds that an account does not exist, a new account record will automatically be created.
The new account record will be created based on the master account record and will inherit the
following values from the main record:
• Customer
• Category
• Currency
• Account Officer
• Reconcile Acct
• Our Ext Acct No
• Dispo Officer
Additionally a new table AC.AUTO.ACCOUNT will allow definition by account category of additional
rules including:
• Additional fields to be mapped (e.g. Local reference values)
• Numbering rules to be applied for the account
When the sub-account is created, a record is also added automatically in ACCOUNT.STATEMENT

for that account. If the field OUR.EXT.ACCT.NO is set in the sub-account, the AGENCY record for
that customer is also updated.
Numbering sub-accounts
When using Sub accounts with internal accounts and internal Inter-company accounting the Sub
accounts can be set up to increment using either the CATEGORY or SUFFIX part of the account
number.
For example in a multi-book area an inter-company account will be formatted like
USD-11500-0001-0033
If the field INT.ACC.TYPE in AC.AUTO.ACCOUNT is set to CATEG then when sub accounts are
automatically opened by the system, it is the CATEGORY section of the account number that will be
incremented, up to the MAX.SUB.ACCOUNT (defined in the master account). For example the above
account number will become:
USD-11501-0001-0033
However should SUFFIX be defined in INT.ACC.TYPE in AC.AUTO.ACCOUNT, then

USD-11500-0001-0033 would be incremented as USD-11500-0002-0033.
However it is recommended that if using SUFFIX with Sub accounts for inter-company
Accounting that the SUB.SIVISION code of the Multibook's be well spaced for example using 0100,
0200 rather than 0001, 0003 as this will effect the logical creation of sub accounts.

AC.AUTO.ACCOUNT
Figure 402 SETTING UP RULES FOR SUB-ACCOUNT CREATION FOR A/C CATEGORY
Numbering rule for sub account

The field NEW.NUMBER.RULE will indicate the system how to generate the account number for the
new sub account.
It can either contain the value “NEXT” in which case the system will allocate the next id using the
check-digit rule defined in the COMPANY record, otherwise, it can contain the name of a routine that
will return a new account number.
Inherited fields
Some fields will be inherited by the sub-accounts by default, however the sub account may inherit the
values of additional fields from the master account. The fields that the sub account will inherit must be
defined under the multi-valued field INHERITED.FIELD.
Fixed value
Some fields may hold a fixed value for sub accounts under a specific category, irrespective of the
value held in the Master account.
The associated fields FIELD.NAME and FIELD.VALUE allow the definition of the fixed value that
some fields will hold.
Any field defined with a fixed value will have priority over the inherited field, hence the field in the sub
account will hold the value defined in the FIELD.VALUE field.

Excluding sub account processing
Although the account is defined as a high volume account, some transactions may be excluded from
being distributed to sub accounts. This may be at application level or at transaction level.
This may be defined under the fields EXCLUDE.SYS.ID and EXCLUDE.TXN
Specific operation on sub account creation
A routine may be called to perform any other operation associated with the creation of the sub account.
This must be defined under the field CREATION.RTN
Processing transaction to a high volume account
The following is an example of processing a DATA.CAPTURE entry to a high volume account
Figure 405 DATA CAPTURE entry to a high volume account

The entry has been distributed to a sub account which has been created automatically:
Figure 406 STMT.ENTRY distributed to sub account and MASTER.ACCOUNT hold value of original
account

The automatic creation of the sub account:
Figure 408 SUB ACCOUNT HAS BEEN AUTOMATICALLY CREATED
Statement Printing
The account statements are generated by Sub Account, that is for each sub account there will be a
separate statement.
Nostro Reconciliation
Consult the Nostro Reconciliation User Guide for details of how sub-accounts will be handled
CONSOLIDATION OF STATEMENT ENTRIES

The field CONSOLIDATE.ENT in the ACCOUNT application indicates that an account is to raise
consolidated statement entries.
To allow the consolidation of statement entries for a specific account, this field should contain a valid
record in the AC.CONSOLIDATE.COND application. This application is a parameter table that defines
simple rules for the consolidation of entries

Figure 410 SETTING THE ACCOUNT TO RAISE CONSOLIDATED STATEMENT ENTRIES
AC.CONSOLIDATE.COND – Consolidation Parameters

The account for which consolidated entries should be raised, must be linked to a consolidation
condition defined in this table, the condition may apply:
• The type of entry that should be consolidated, i.e. forward or live or both may be defined under
field ENTRY.TYPE
• The field EXCLUDE.SYS.ID defines the system ids that should not be consolidated
• The field EXCLUDE.TXN defines the transaction codes that should not be consolidated
• The field EXCL.PROD.CAT defines the Product Categories not to be consolidated for P&L
entries
• The field EXCLUDE.RTN may hold a routine that will indicate if entry is to be consolidated or
not
• Additional fields in the entry to be used in the consolidation may be defined under the field
ADD.CONSOL.FLD
• The field NO.ENTRIES.START determines the number of entries that should be raised for
the day before consolidating for an account.

Figure 412 SETTING UP THE PARAMETER FOR CONSOLIODATION OF ENTRIES
AC.CONSOLIDATE.COND – Default Option for Nostro and Internal account

If the field CONSOLIDATE.ENT is not set in the account record for Nostro and Internal accounts, then
the system will refer to a default record ‘DEFAULT’ in the AC.CONSOLIDATE.COND to determine the
rule for consolidation process.
Figure 414 'DEFAULT' record in AC.CONSOLIDATE.COND

The NO.ENTRIES.START in the ‘DEFAULT’ record is set to 400, which means that consolidation of
statement entries will start once 400 entries have been raised for the day to both Internal and Nostro
accounts.
Consolidated Entry Data

The system will raise consolidated statement entries for those accounts specified, each consolidated
statement entry will be keyed by the following consolidated elements of the entry, each element is
separated by the “!” delimiter.
• Entry Type - S, C or F
• 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
Example of FUNDS.TRANSFER entries consolidated under the same STMT.ENTRY

Figure 416 FIRST FUNDS.TRANSFER ENTRY
Figure 418 SECOND FUNDS.TRANSFER ENTRY

Figure 420 THIRD FUNDS.TRANSFER ENTRY
Figure 422 CONSOLIDATED STMT.ENTRY FOR THE FT ENTRIES

The detailed statement entries generated by the three FT entries have been consolidated based on
the consolidation criteria defined above.
The AMOUNT.LCY and AMOUNT.FCY from the detailed entries are added to the value in the
consolidated entry. A new EXCHANGE.RATE is calculated based on the value of the local and foreign
amounts.
The TRANS.REFERENCE and OUR REFERENCE in the consolidated entry contain the value NET-
consolidated id.
The original SYSTEM.ID is suffixed with the value NET – this will allow existing enquiries to drilldown
to the consolidated entry rather than the originating application since the contract reference will not be
present. The STMT.NO field will indicate the number of statement entries that have been consolidated.
Detailed Statement Entries

The system keeps the link between the main consolidated entry and the detailed entries in
STMT.ENTRY.DETAIL.XREF while the detailed statement entries are held in STMT.ENTRY.DETAIL.
STMT.ENTRY.DETAIL.XREF
In order to keep these records a manageable size in STMT.ENTRY.DETAIL.XREF, every 200

detailed statement entries under a consolidated statement, a new record is created and the sequence
number is incremented by one.
The id to the STMT.ENTRY.DETAIL.XREF is the consolidated statement id-the sequence number and
each record will hold up to 200 statement entry ids.

Figure 424 THE STMT.ENTRY.DETAIL.XREF SHOWING THE STMT.ENTRY IDS

CONSOLIDATED
STMT.ENTRY.DETAIL
The STMT.ENTRY.DETAIL application is a replicate of the STMT.ENTRY but which holds only the
detailed statement entries that have been consolidated. The Detail Id is the key to
STMT.ENTRY.DETAIL and it will hold the details of the statement entry.
The following shows the details of the two entries that have been consolidated:

Figure 426 DETAILED ENTRY FOR THE FIRST DETAIL.ID

Figure 428 DETAILED ENTRY FOR SECOND DETAIL.ID

Figure 430 DETAILED ENTRY FOR SECOND DETAIL.ID
Statement Printing
Although the statement entry is consolidated, the statement contains the contents of detailed entries.
Nostro Reconciliation
The NR.STATEMENTS will also include the details as per THE STMT.ENTRY.DETAIL.
The following shows the NR.STATEMENT record generated for the account.

Figure 432 NR.STATEMENTS record containing the detailed entries
The NR.ITEMS that will be used for reconciliation

Figure 435 NR.ITEMS SHOWING THE DETAILED ENTRIES
CONSOLIDATION OF CATEGORY ENTRIES

CATEGORY may also indicate that consolidated P&L entries are to be raised if the
CONSOLIDATE.ENT field holds a valid record in the AC.CONSOLIDATE.COND.
The system will then raise consolidated category entries for those categories specified, the detail of
the underlying entries will be maintained in a new file, CATEG.ENTRY.DETAIL. Details will be linked
to the consolidated entry by a cross-reference file CATEG.ENTRY.DETAIL.XREF.
The consolidated entries will be written to the CATEG.ENTRY file and will be the entries presented in
standard account statements and enquiries.
ARCHIVING
The detailed entries that have been consolidated will be archived every six months. The detailed
entries are extracted from the consolidated statement entry id in the ACCT.STMT.PRINT. The
STMT.ENTRY.DETAIL record in ARCHIVE defines the archiving details for the detailed statement
entries.


STATEMENT PRINT MASKING
Introduction
It is possible to mask accounting entries, where entries have either been posted incorrectly and had to
be reversed out, or other financial postings that customers do not want on their statements.
Masking is also necessary because some customers reconcile directly against the statements they
receive from the banks and unexpected entries can cause confusion to their reconciliation’s. This is
especially true when the statement is delivered electronically and the customer uses it to reconcile
internally within their computer systems.
Masking will only apply to statements only. The entry will not be removed from the account and the
transaction will not be deleted it, it just will not show on the statement.
Setting up the statement masking
A field called MASK.PRINT exists in STMT.ENTRY to indicate whether certain statement entries
should be masked from printing, or not. To update the MASK.PRINT field AC.PRINT.MASK allows
users to flag statement entries manually that customers do not want to see on their statements. The
selection of entries to be masked for a particular account will be assisted by the provision of
STMT.ENTRY enquiries.
Once the statement entries have been captured into AC.PRINT.MASK application, the system will
then perform routine validations on the selected entries, firstly to ensure the integrity of the selected
items and to also make sure that the net movement of the selected entries is zero.
Once all the routine validations have taken place, the statement print programs or formatting enquires
must now check the MASK.PRINT field on the STMT.ENTRY record, if the value of the field is true
then the entry should not be displayed.
AC.PRINT.MASK
As mentioned before, the AC.PRINT.MASK application has been produced to allow users to go in and
manually flag certain statement entries that have to be omitted from customers’ statements. This
section will show you how to set up an AC.PRINT.MASK record and explain the rules and validations
of the application.

Figure 436 - AC.PRINT.MASK
First of all run the application AC.PRINT.MASK and capture and id which can be automatically
generated by setting up an AUTO.ID.START record for AC.PRINT.MASK and by also making sure
that the application exists in the COMPANY record under the PG.AUTOM.ID. Once you have
captured the id you will be required to capture the account number of the customer and the current
date in MASK.DATE. Enter dates in ENQ.START.DATE and ENQ.END.DATE. These dates are
captured to ensure that statement entries that are to be masked fall within the start dates and end
dates. If you do not enter any dates into these fields a default date of today will be captured in those
fields. The MASK field will indicate whether the statement entries should be masked and unmasked.
You can capture either “YES” or “NO” and which is mandatory. The MATCHED.TO field is used to
capture all the statement entries you wish to mask or unmask, however they must all be debit entries
or all credit entries. You cannot mix debit and credit entries in the same field. The same applies to the
MATCHED.FROM field. You can use STMT.ENTRY enquiries to pick the entries you wish to select to
update the relevant fields in STMT.ENTRY. There is an example below that explains how to run the
enquiries and to select, copy and paste the relevant entries into the MATCHED.TO and
MATCHED.FROM fields.

Figure 438 - Example STMT.ENTRY
This is an example of all the statement entries that are associated with account number 0000001775.
To bring up this list you have to run an enquiry on the STMT.ENTRY application of all statements that
belong to the particular account that you want to mask.
Figure 439 - Individual entry
Once you have found the statement entry that you wish to mask or unmask for printing on the enquiry
list, you then double click on the statement entry and the full record for the statement entry will then be

displayed as shown in Figure 0-3. You then highlight the statement entry id at the top of the record
and right click on the mouse and copy the id.
Once you have copied the statement entry id, you then go back to the running AC.PRINT.MASK
application, move your mouse to either the MATCHED.TO or MATCHED.FROM field, right click on them
and then paste the id into the field and hit enter. Once you hit enter, the fields TO.TOTAL and
FROM.TOTAL as well as the NET.TOTAL field will be updated with totals in the statement entry
record. Once again, make sure that your MATCHED.TO and MATCHED.FROM fields consist of either
all debit or all credit entries.
When all the entries have been captured you can then commit and authorise the record, but the
system will make sure that the net movement between the statement entries captured is zero.
Once the authorisation takes place the relevant STMT.ENTRY records will be either masked or
unmasked for printing at a later stage.
AC.PRINT.MASK
Key Description
ACCOUNT.NO Account number of the statement entries you
want to flag.
MASK.DATE Current date of the system.
ENQ.START.DATE The start date for the selection of entries by
booking date.
ENQ.END.DATE The end date for the selection of entries by
booking date.
MASK Indicates whether the statement entries captured
should be masked (YES) or unmasked (NO).
MASK.NARRATIVE Descriptive field used to update the entry.
MATCHED.TO This is where the statement entry id from
STMT.ENTRY file is captured to be matched. If
there is more than one then they must be all
debits or all credits entries.
TO.TOTAL This will be updated by the system. This is the
total sum of all the MATCHED.TO entries.
MATCHED.FROM This is where the statement entry id’s from the
STMT.ENTRY file are captured. If there is more
than one they must be all debits or all credits.
MATCHED.FROM This is where the statement entry ids from the
STMT.ENTRY file are captured. If there is more
than one they must be all debits or all credits.
FROM.TOTAL This will be updated by the system. This is the
total sum of all the MATCHED.FROM entries.

ET.TOTAL This is updated by the system. If the net total of

the TO.TOTAL and FROM.TOTAL is not zero
then an error will be generated.
NET.TOTAL This is updated by the system. If the net total of
the TO.TOTAL and FROM.TOTAL is not zero
then an error will be generated.
Figure 440 AC.PRINT.MASK
US REGULATION D COMPLIANCE
US Regulation D Compliance
In order to allow the record of any Regulation D violation on-line, the Core Accounting module has
been modified to facilitate this regional development, by allowing a locally developed accounting sub
routine to be defined.
This routine will accept accounting entries, and optionally return a list of override messages at the
input stage, i.e. for unauthorised entries.
The rule to generate the overrides is defined in the local subroutine, an example program namely
AC.TEST.NAU is provided.
Although other user processing may also take place, care must be taken to ensure system
performance is not affected.
Note: Original Note: Original entries cannot be changed.
The core system will then process these overrides, including the possibility of logging them with the
DISPO module.
Setting up the routine
The routine must be defined a ‘S’ type in PGM.FILE.

Figure 442 - Setting up the Local Routine
Account.Parameter
ACCOUNT.PARAMETER
The Core Accounting routine will fetch the local routine if it is defined in ACCOUNT.PARAMETER
under ACCT.NAU.SUBRTN.

Figure 444 - Defining the Local Routine in ACCOUNT.PARAMETER
Override Messages
When a transaction is being processed the Core Accounting routine will process all the system
overrides then will call the local routine and generate the local overrides.
As from the example program, an override message ‘HAVE A NICE DAY’ is generated at the
transaction input stage.
The example below shows a Funds Transfer input and the flow of the override message. Once the
system overrides have been raised then the local ones will be raised.

Figure 446 - First system override showing same debit and credit account
Figure 448 - Second system override showing unauthorised overdraft

Figure 450 – Override from local subroutine is raised

Accounts Interests and Charges PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Accounts Interests and Charges PDF

Transféré par

Droits d'auteur :

Formats disponibles

TEMENOS T24

Accounts, Interest and Charges

Information in this document is subject to change without notice.

Copyright 2005 TEMENOS Holdings NV. All rights reserved.

TEMENOS T24 User Guide Page 2 of 355

Internal Files................................................................................................................................. 133

TEMENOS T24 User Guide Page 3 of 355

• Calculation of interest on client accounts.

The processing options available on client accounts include:

TEMENOS T24 User Guide Page 4 of 355

These options are detailed later in this guide.

An example of a simple current account is shown below:

Figure 1 Client Account

TEMENOS T24 User Guide Page 5 of 355

Figure 2 Nostro Account

TEMENOS T24 User Guide Page 6 of 355

An example of a simple internal cash account, is shown below:

Figure 3 Internal Account

TEMENOS T24 User Guide Page 7 of 355

Account Number Format

The following values will be accepted:

'1': When LOCAL.CURRENCY starts with BE (i.e. identifies Belgium).

TEMENOS T24 User Guide Page 8 of 355

Figure 4 Internal Account ID Structure

The ACCOUNT will have the text ‘RECORD.AUTOMATICALLY.OPENED’ set in fields

Customer Account input

TEMENOS T24 User Guide Page 9 of 355

Figure 5 Client Account

• Interest rates and methods

TEMENOS T24 User Guide Page 10 of 355

Internal account input

Figure 6 Internal Account

TEMENOS T24 User Guide Page 11 of 355

TEMENOS T24 User Guide Page 12 of 355

2) VALUE.DATE if exposure date is blank

3) BOOKING.DATE if value date is blank

While for debit transactions the following order is applied:

TEMENOS T24 User Guide Page 13 of 355

2) BOOKING.DATE if value date is blank

Available Funds Window

If today’s date is 13th of April 2000, and CASH.FLOW.DAYS is set to 10 then:

Window start date will be 13th April 2000

TEMENOS T24 User Guide Page 14 of 355

Figure 7 Account Parameter showing the cash flow window

Transactions beyond the Window

TEMENOS T24 User Guide Page 15 of 355

Here is the account before a back-valued transaction is entered:

Figure 8 Existing account before back-valued transaction entered

TEMENOS T24 User Guide Page 16 of 355

Figure 9 Enter funds transfer to debit account

TEMENOS T24 User Guide Page 17 of 355

Figure 10 Account after debit payment has been passed

AV.AUTH.DB.MVMT - authorised debits

TEMENOS T24 User Guide Page 18 of 355

More details on EB.AF.PARAM are described below.

Open Available Balance

BOTH - Unauthorised debits and credits to make up available balance

This option is also available at ACCT.GROUP.CONDITION and ACCOUNT level.

• Null or WORKING - check overdraft and cash flow

TEMENOS T24 User Guide Page 19 of 355

This option is also available in the ACCT.GROUP.CONDITION, SEC.ACC.MASTER and ACCOUNT

Available Balance Excess

Available Balance Overdraft