Accounts

T3IMBR - Accounts - R9.
01
ACCOUNT application caters to creation and maintenance of all types of accounts

handled by T24. In T24, Accounts can be classified as two types, namely Customer
account or Internal type of account. Customer accounts are accounts opened for and
owned by external customers. External customers in the sense that it should be a
valid counter party. Internal accounts are accounts maintained by the bank for its
own purpose, like cash account, Travelers' Cheque etc.
Accounts module provides for calculation, accrual and application of interest on
customers' accounts. Interest could be either a Fixed or a Floating rate. Further it
can be level or banded. In addition, it is used for calculation of charges relating to
maintenance and servicing of accounts. Rules for interest and charges can be set for
an individual account or for a group of accounts.
It is also used for production of account statements and issue of passbook for certain
class of customer accounts.
It is possible to handle cheque book management in T24 like issuing, controlling
stock, recording payment, noting and effecting stop payment instructions.
By linking to another related module called image management it is possible to
verify signature of account holders. Sweeping of balances between accounts can
also be handled. ACCOUNT module has a separate application called
ACCOUNT.CLOSURE for closing accounts.
T3IMBR - Accounts - R9.01
It is possible to set preferential service conditions for maintenance of accounts. The

conditions are related to various activities which happen during the lifecycle of an
account . Preferential conditions may be set for interest, charges, other tariff
structure, accrual, and statements production. Groups are determined based on the
selected elements from CUSTOMER and ACCOUNT record. The priority data
items from customer and accounts are defined in the CONDITION.PRIORITY
table for the record ACCOUNT.
Conditions for the calculation and application of interest and charges may be
specified at the group level. If an account needs to be set up with different service
conditions from the group to which it belongs, the group conditions are overridden
with special conditions set for individual account level. When ever an account is
opened, it is linked to the appropriate group based on the details of underlying
Customer and nature of account. There must always be a default group created for
accounts.
Basic elements for interest and charges calculation required are (1) when
capitalisation is done and (2) at what frequency it is done. This is required
separately for Debit interest and Credit interest as they can differ.
Interest type that is used in the calculation i.e. fixed or floating are set up currency
wise. Interest rates may be set up as level or banded interest rates with the
effective dates . T24 provides the flexibility to calculate interest based on daily,
average or minimum balance available for credit interest calculation in the account.
Similarly it is possible to set debit interest based on daily, average or maximum
balance .
It is possible to set up different type of interest related and ledger fees related
charges. Interest should be defined with effective dates and for each currency.
Interest rates can be set up as fixed or floating. Rate with level and banded structure.
Balance on which interest is calculated can be specified as daily or average or
minimum for credit interest & maximum for debit interest.
The set up of interest and charges grouping for Accounts structure starts with
CONDITION.PRIORITY table. T24 permits us to decide the order of priority to
apply criteria for creating groups for differential treatment.
Based on the priority and criteria chosen in CONDITION.PRIORITY, the actual
fields are created in ACCT.GEN.CONDITION. Rules and values to criteria, when
specified in this table, will group account records when opened into appropriate
groups. It is mandatory that a default group with no conditions should be setup
before we go on to create conditions attached groups.
Based on these groupings, Capitalisation rules, debit interest conditions and credit
interest conditions for each group need to be setup in GROUP.CAPITALISATION,
GROUP.DEBIT.INT and GROUP.CREDIT.INT. If needed, account specific rules
for all or some of the above 3 can be defined in ACCT.CAPITALISATION,
ACCOUNT.DEBIT.INT and ACCOUNT.CREDIT.INT files.
Charges related setup is done in related files and linked to GENERAL.CHARGES
which is then attached to GROUP.DEBIT.INT or ACCOUNT.DEBIT.INT. At least
one record for default charges is mandatory in GENERAL.CHARGE.
CONDITION.PRIORITY table is used to define criteria like nationality, industry ,

sector etc available in the CUSTOMER application and product category, currency
from the ACCOUNT application.
For example, groups could be saving account of residents , saving account of non
residents , current account of corporates engaged in software industry and current
account of private citizens of US nationality. In these examples, criteria used are
residence , nationality , industry and sector from CUSTOMER application and
savings and current accounts from ACCOUNT application.
Separate rules should be setup for interest and charges and statement purposes with
record Id in CONDITION.PRIORITY as ACCOUNT and STATEMENT
respectively. If company wise rules are required to be set up then the record Id of
CONDITION.PRIORITY is suffixed with a - (hyphen) and company code
namely ACCOUNT-company code and STATEMENT-company code. Else the data
items will default from ACCOUNT and STATEMENT record Ids .
For example: If separate rules for interest and charges are required for a company
GB0010001 and GB0010002, then two records with ids ACCOUNT.GB0010001
and ACCOUNT.GB0010002 are required.
If 3 companies setup with defaulting rules different only for third company namely
GB0010003, then 2 records namely ACCOUNT and ACCOUNT-GB0010003 is
setup, where the former is default conditions applied to first 2 companies.
In CONDITION.PRIORITY , you can rank the proposed selection criteria and

indicate the applications from where the data is to be chosen. Allowed applications
are ACCOUNT and CUSTOMER. Any single value or local reference fields from
these applications can be chosen for making the selection criteria.
PRIORITY.ITEM is a multi value Field which defines the file and field from that
file used for criteria definition. The format is APPLICATION>FIELD.NAME. For
example, in the CONDITION.PRIORITY record for ACCOUNT, the
PRIORITY.ITEM field with ACCOUNT>CATEGORY implies that CATEGORY
Field from the application ACCOUNT is an element of criteria.
PRTY.VALIDATION Field indicates details of validation to be displayed as
enrichment for the group definition. For example: In the above when field is set as
CATEGORY>DESCRIPTION, then for a value entered in
ACCT.GEN.CONDITION , System validates with CATEGORY table and
DESCRIPTION in that CATEGORY record would be displayed as an enrichment. It
is also possible to attach a routine for validation.The order in which
PRIORITY.ITEM is defined in the multi value set determines the priority of the
item. For example : PRIORITY.ITEM.1 and PRIORITY.ITEM.2 when defined as
ACCOUNT>CATEGORY and CUSTOMER>SECTOR implies that Category from
Account is of higher priority than the other.
The selection criteria for preference groups can be amended along with or without
change in the ranking conditions. Dated CONDITION.PRIORITY records are
required to be created to achieve this. The effective date could be either processing
date or future date.
Id will be of the format ACCOUNT--<DATE>. The value in the middle field of Id
can be used for company specific definition. Based on the previous selection
criteria, general and group specific conditions would have been built. As a result of
the new selection criteria there would be a need to re-define rules for some or all of
the groups.
While defining CONDITION.PRIORITY records applicable in future , it is
possible to specify which ACCT.GEN.CONDITION and
ACCT.GROUP.CONDITION records need to be retained by specifying their Ids in
GEN.COND.KEEP and GROUP.COND.KEEP Fields.
During COB processing on the specified date, these ACCT.GEN.CONDITION
records would be automatically modified with priority data items applicable for the
new structure, existing priority data items and their values will be retained...New
priority items will be updated with null values.
Advised to leave GEN.COND.KEEP as null so that old records are removed and
new ones redefined. GROUP.COND.KEEP can also be set as ALL to retain all
existing records.
10
11
Lay out of ACCT.GEN.CONDITION and STMT.GEN.CONDITION is dependent

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

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

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

Credit2, Debit and Debit2 interest. For example, for accounts of Private individual
residing in UK and USA classified as group 1 we can set the capitalisation
frequency as last date of every month for debit interest and to pay interest for credit
interest at the end of every quarter.
On the other hand we can set up for group of current accounts of Corporates to debit
interest every quarter on the last date while for credit balances in the same accounts,
interest is not payable.
SETTLE.ACCT.CLOSE Field is used to indicate whether settlement account is
required while closing accounts falling under this group.
15
16
17
18
19
Rules have to be set up group wise and currency wise to take effect from the
indicated dates for each of the groups created in ACCT.GEN.CONDITION. Then Id
can be 1USD25JAN2008, where 1 is the group Id set up for USD with the effective
date.
General charges and applicable taxes for the group are indicated in CHARGE.KEY
and TAX.KEY Fields. CHARGE.KEY Field is mandatory. Even if there are no
charges to be recovered a null charge key is to be indicated.
TAX.KEY Field hold ids of Tax records (defined in TAX table) or
TAX.TYPE.CONDITION records with a "*" symbol prefixed, which specifies the
calculation and processing of taxes say one or more, applicable to debit interest. If
linked to tax record , then tax rate is applicable on all accounts in the associated
group of accounts. In the latter case, Tax can be collected based on customer related
conditions. CONDITION.PRIORITY needs to be defined for TAX and grouping
rules defined in TAX.GEN.CONDITION. For each grouping condition, the actual
tax rates available in TAX table will be linked to a TAX.TYPE.CONDITION by
defining it in TAX.CODE Field. Hence, when TAX.KEY in GROUP.DEBIT.INT is
defined with an identifier of TAX.TYPE.CONDITION, then the system will derive
the applicable tax rates based on the customer grouping. No tax is applied if interest
is not calculated. The tax record, if attached must be in existence with an effective
date not later than effective date of GROUP.DEBIT.INT.
20
INTEREST.DAY.BASIS gets its default value from respective CURRENCY table

. If it is to be different, then it is possible to indicate the same. If debit interest need
not be calculated, then NONE to be indicated.
Debit interest can be calculated on daily, average or highest balance during the
interest period. The required balance types used for interest calculations to be
defined in DR.BALANCE.TYPE is chosen as AVERAGE for Average balance
taken during the interest period or DAILY for Daily balance taken or HIGHEST for
the highest balance during the interest period.
It is possible to set different rates for range of balances by multi valuing interest
related fields. The calculation method can be effected using LEVEL or BAND type
interest calculation defined through DR.CALCUL.TYPE Field.
For example: Let us take the interest rate to be indicated as 5% for balances up to
USD 5,000 and 6% thereafter. If the account has got a debit balance of USD 6,000,
then under level calculation, 6% interest on entire balance is applied.
But on the other hand, under band calculation, 5% on first 5,000 and 6% on the
remaining 1,000 is applied.
21
When more than one rate of interest is mentioned namely for a level/band
calculation type, then it is possible to define amount up to which the first rate is
applied using DR.LIMIT.AMT. If no limit is specified for the first level and if
second level rates are input , the first rate is applicable up to the overdraft limit
specified for each Account in ACCOUNT.DEBIT.LIMIT table. When more than 2
levels of rates are defined, then it is a mandatory input.
It is possible to apply fixed or floating rates and different choices are possible for
different balances. It could be fixed for the first slab and floating for the second
slab or floating for the first slab and fixed for the second slab.
Fixed interest rate can be input through DR.INT.RATE Field.
To indicate floating rate, it is linked to BASIC.INTEREST, through
DR.BASIC.RATE Field. Over the floating rate it is possible to apply margin by
adding or subtracting or multiplying using DR.MARGIN.OPER and indicating the
margin in DR.MARGIN.RATE Field.
For example: Current rate 6.75%. If margin rate of 10 is to be multiplied to this
rate, effective rate is 7.425%, being 110% of 6.75
If floating rate is opted, it is possible to indicate a floor rate of interest in
DR.MIN.RATE Field. If this is indicated as 4, then the final rate to be applied on
the account after taking into account the floating rate and its spread, will be at least
4%.
22
If a minimum amount of interest is to be collected from an account, then it is

specified in DR.MIN.VALUE. Interest will be accrued on the account normally. If it
is less than the minimum amount indicated here at the time of capitalisation, then it
can be optionally waived or not. If DR.MIN.WAIVE is set to YES, then debit
interest amounts below the minimum value will be waived and not debited to the
account and if it set to NO, then value in DR.MIN.VALUE will be collected.
In the similar manner rules can be set for second interest to be debited from the
respective accounts, over and above the first interest.
All the fields are prefixed with DR2 for this purpose.
For example : A bank may charge additional interest on accounts with average debit
balance under USD 50,000 .
COMPOUND.TYPE Field is used to specify the number of compounding periods
per year. Optional values for the field are DAILY, WEEKn, Mnn or Nnn. If left
blank, no compounding will occur.
23
Annual Payment Rate (APR) is the equivalent interest rate considering all the
added costs. This is known as TEG in France. It is arrived at based on interest
rate, total added cost, and terms. For an advance, the APR is the interest rate plus
charges plus any other incidentals payable to the Bank. APR would be equal to
interest rate if there is no additional cost s. If this is required to be indicated in the
underlying accounts, APR.REQUIRED Field should be set to yes. If APR is not
required, this field is set as NO.
MAX.LEGAL.RATE Field is used to indicate the maximum legal rate applicable to
the group. It acts like a cap.
MAX.DEBIT.CHG.RATE Field identifies the maximum allowed charge as a
percentage of the first debit interest amount. For example, if it is set as 40%., then
the total charges should not exceed 40% of the interest to be collected.
The values that need to be defaulted into these three fields can be stored in
GROUP.CONDITION table. GROUP.CONDITION is used to define Group Level
conditions for calculation and application of interest, charges and APR . Id of
GROUP.CONDITION table chosen should match with the Group Id indicated in
GROUP.DEBIT.INT table.
24
25
26
GROUP.CREDIT.INT table allows rules for calculation of credit interest for groups
of accounts. It is quite similar to GROUP.DEBIT.INT with a few additional
capabilities. The Id will comprise Group Id, Currency and effective date each
separated by a .
TAX.KEY Field identifies either a Tax record (defined in TAX table) or
TAX.TYPE.CONDITION record with a "*" symbol prefixed, which specifies the
calculation and processing of tax, applicable to credit interest. Input of
TAX.TYPE.CONDITION helps in deducting different rates of tax for different
group of customers within the associated group of accounts. INTEREST.TAX.MIN
Field defines the amount of interest which can be earned tax free. If the amount of
credit interest earned in a capitalisation period is greater than this amount then tax,
if defined, will be deducted. The minimum interest taken for tax calculation will be
for CR interest and CR2 interest individually and not for the sum of the two.
It is possible to net debit interest against credit interest prior to calculating tax , if
both are capitalised on the same dates. DR interest can be netted against CR interest
and DR2 interest can be netted against CR2 interest.
27
Similar to the features in GROUP.DEBIT.INT, it is possible to set rules for first and second
credit interest as fixed and/ or floating interest rate. The rates could be on a level or band
basis. Similarly, it is possible to waive or pay a minimum amount of interest.
CR.MAX.RATE Field is used to define the capped rate for credit balance type. If the rate
that is derived after applying any spread, is more than this rate then interest rate will be
capped at this value. Credit Interest can be calculated on daily, average or minimum balance
during the interest period by defining in CR.BALANCE.TYPE Field. If MINIMUM is
opted , the minimum balance during a period within a month is used for interest
calculations. It is possible to set negative interest rates on accounts in credit. To achieve this
, NEGATIVE.RATES Field on GROUP.CREDIT.INT must be set to YES. If this field is set
as either No or left unpopulated, then when interest rates fall below 0, zero interest will
be accrued to that account. If set to YES, this would enable collecting interest from accounts
even though they have credit balances.
Negative interest rates may occur by CR.BASIC.RATE being specified with a discount ,
such that the net effective rate is negative. This is useful for penalising overdraft accounts
maintaining credit balance. If set to BLOCK.MARGIN, negative effect will not be allowed
because of margin. Negative margin can not make the rate more negative or a positive rate
to negative. For Example, If base rate is -7, margin is -2 then net effect will be -7.If margin
is +2 then the effective rate become -5. If base rate is +5 and margin is -7 then effective rate
will be zero not negative.
28
Minimum balance in account for interest calculation can be specified in

CR.MINIMUM.BAL along with start and end dates maintaining such minimum
balance is specified in CR.MIN.BAL.ST.DTE and CR.MIN.BAL.ED.DTE
respectively. If accounts are opened or closed between these dates, then processing
is as defined below.
When CR.ACCR.OPEN.AC is set as Yes, then credit interest is calculated on
minimum balance between the opening date and end date provided balance type is
minimum. When set as NO, then no interest is applied to the account for the month
of opening.
Similarly CR.ACCR.CLOSE.AC is used for account closed during the period.
When set as Yes, then end date for minimum balance calculations is taken as the
closure date of the account to enable it to receive interest for the month.
CR.ZERO.INT.BAL Field indicates that credit interest will not be paid for the entire
capitalisation period if the balance in the account falls below the value indicated
here. If a minimum balance is indicated in this field, input into CR.ZERO.INT.OC
Field will determine whether any accounts opened or closed during the
capitalisation period will have interest paid. NO or Null input will result in no
interest being paid. YES input will result in interest being paid dependent upon the
value in CR.ZERO.INT.BAL.
29
It is possible to specify that credit interest is to be calculated only for offset against
debit interest and not for crediting the Customer's Account by using
CR.OFFSET.ONLY Field. If the field is set as Y, then first credit interest will be
offset for first debit interest only.
Input to this field has no effect unless the debit and credit capitalisation dates are the
same.
When CR2.OFFSET.ONLY is set to Y, then only the second Credit Interest specified
in the CR2 Fields may be used to offset the second Debit Interest specified in DR2
Fields .
30
31
32
The charges applied to an account will vary from different categories of account.
Charges are of two types interest related and ledger fee related .
Interest related charges include DEBIT.INT.ADDON or HIGHEST.DEBIT,
GOVERNMENT.MARGIN and INTEREST.STATEMENT Charge.
The ledger fee related charges can be based on BALANCE.REQUIREMENT,
NUMBER.OF.CREDIT or TURNOVER.CREDIT, NUMBER.OF.DEBIT or
TURNOVER.DEBIT, ACCT.STATEMENT.CHARGE and non immediate
TRANSACTION.CHARGE depending on the Transaction Codes.
TRANSACTION.CHARGE is not attached through GENERAL.CHARGE . It is
attached through TRANSACTION record in CHARGE.KEY Field.
All charges are linked through GENERAL.CHARGE . Several such charge tariff
structures may be stored in the file GENERAL.CHARGE. Charges effective on the
date of capitalisation are applicable for the whole of capitalisation period.
A particular GENERAL.CHARGE record could be linked to a GROUP.DEBIT.INT
record or to a single account through ACCOUNT.DEBIT.INT. This brings out the
whole picture of charge structure for accounts.
33
The GENERAL.CHARGE record applicable to a particular Account is specified in

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

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

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

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

as single debit. Depending on CHARGE CODE LEVEL, individual or combined
charge amounts are calculated. CHARGE.CODE.LEVEL Field is set to COM for
combining charges and IND for individual transactions of charges.
LOW.AMT.CHARGE Field specifies the smallest amount of charges specified in
BAL.REQUIREMENT, NUMBER.OF.CREDIT, NUMBER.OF.DEBIT,
TURNOVER.CREDIT, TURNOVER.DEBIT and STATEMENT.CHARGE, which
will be booked, for Accounts in the Currency specified in the corresponding
OFFSET.CURRENCY. If calculated charges are less than this amount, they will be
waived.
In the absence of a defined currency, individual or combined charge amounts are
converted to local currency equivalent. If the result is less than the amount specified
in DEF.LOW.AMT.CHARGE, the charge is waived.
Currency wise charges below stipulated amounts or individual charges can be
waived.
38
When Account maintenance charges are combined, it is possible to set rules for
waiving or offsetting. This is achieved depending on the value in the
OFFSET.BAL.TYPE Field. The options available are MINIMUM and AVERAGE.
If accounts maintain the balance indicated charges can be waived.The Average or
Minimum balance for the application period is calculated and converted to local
currency equivalent. If the result is not less than the DEFAULT.MIN.AV.BAL all
charges specified in BALANCE.REQUIREMENT, NUMBER.OF.CREDIT,
NUMBER.OF.DEBIT, TURNOVER.CREDIT, TURNOVER.DEBIT and
STATEMENT.CHARGE are waived.
It is also possible to calculate a notional credit interest amount and can be offset
against the calculated charges. DEFAULT.BAL.NO.OFFSET Field specifies the
balance (in local currency equivalent) required before offset interest is calculated
for Accounts in Currencies with no such details.
Details for waiving charges and calculating offsets for Accounts, in specific
Currencies may be specified in the multi value group of associated
OFFSET.CURRENCY, MIN.AV.BAL, DAY.BASIS, BAL.NO.CREDIT and
LOW.AMT.CHARGE Fields.
PERCT.FOR.OFFSET Field is used to indicate the rate. DEFAULT. DAY.BASIS
or DAY.BASIS are used to indicate the interest day basis to be used in the
calculation.
39
Purpose of the ACCOUNT ACCRUAL table is to provide the system with

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

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

accrual is to be made. NONE option is used for no accruals. The frequency can be
set up differently for a select group for any select category also. It could be different
for foreign currency accounts and local currency accounts or on a common
frequency for both.
GRP.ACCR.TYP contains LOCAL, FOREIGN or BOTH to indicate whether
accruals happen for accounts of which currency at frequency specified in
GRP.ACCR.FQU Field. ACCRUAL.GRP Field is defined with appropriate group
defined in ACCT.GEN.CONDITION for which the above rules are to be applied.
In the similar manner for specific categories the corresponding fields
ACCRUAL.CAT, CATEG.TYPE and CAT.ACCR.FQU are used to specify the
accrual frequency for suitable categories.
If there are no group or categories specified then DEFLT.ACCT.TYPE Field is used
to indicate LOCAL, FOREIGN or BOTH.
DEFLT.ACCT.FQU Field is used to indicate the frequency. If NONE option is used
then accrual and capitalisation dates are same.
42
Select parameters for operating accounts are set up through this table. It is possible
to set parameters group wise and currency wise.
Notice Savings accounts can be defined to insist on a notice period for withdrawals
above an indicated amount. These are possible for accounts defined as SAVINGS in
ACCOUNT.CLASS.
NOTICE.AMOUNT Field specifies the maximum amount which can be withdrawn
without notification being required. Maximum local currency amount that can be
withdrawn in a single transaction without incurring an override message. Override
message is generated when this value is exceeded.
NOTICE.PERIOD Field can be specified either in days or months or working days
to indicate the notice to be given for withdrawing above the notice amount.
The number of days, months or working days for which funds subject to notice
conditions will be available could be indicated through AVAILABILITY Field For
example: Notice of one month is required for withdrawal and availability of funds
kept for 5 more days, then NOTICE.PERIOD is mentioned as 1 month and
AVAILABILITY as 5 working days. If the amount is not withdrawn within in this
period, fresh further one month notice must be given.
Notice of withdrawal recorded through NOTICE.WITHDRAWAL application.
43
Operational restrictions on maximum increase , allowing debits, minimum and

maximum balances can also be stipulated.
MAXIMUM.INCREASE Field defines the maximum annual balance increase
allowed for this category of account. Calculation of this increase is based on the
start of year opening balance through START.YEAR.BAL Field in the account
record and the current online cleared balance through ONLINE.CLEARED.BAL
Field.
For example , if an account balance can only be increased by 10,000.00 per annum.
The opening balance at start of current year is 50,000.00. Override is raised when
balance greater than 60000.00. If todays balance of 43,000.00 then 17,000.00 can
be drawn to reach the limit.
DEBIT.RESTRICT Field can be used to restrict the accounts that belong to this
group and currency from making debit transactions if set to 'Y'. Text of override
message as defined in RESTRICTED.MSG is displayed accordingly.
It is possible to calculate premium interest rates , then multi valuable
PREMIUM.TYPE Field should be defined with valid records from
SAVINGS.PREMIUM. SAVINGS.PREMIUM file is used to specify the premium
related parameters for accounts.
Minimum and Maximum balances an account is supposed to maintain are indicated
in MINIMUM.BAL and MAXIMUM.BAL Fields. Wherever withdrawals and
deposits breach the rules , it will attract override.
44
It is possible to defer collecting charges, interest and tax thereon for a specific
period after calculation, so that customer could be notified of ensuing debits. The
system debits this amount to internal account and after the deferred period, the
amount is debited to customers account automatically.
DEFER.CHARGE.DAYS and DEFER.DB.INT.DAYS Fields are used to specify
the deferment period. The period can be indicated either in calendar or working
days. The internal account category for posting such debit is indicated for deferred
interest, charges and tax through CHARGE.PENDING.CATEGORY,
DB.INT.PENDING.CAT and TAX.PENDING.CAT Fields. Internal accounts to be
opened in local currency.
It is possible to restrict use of one limit for only one account , instead of many
accounts using the same limit. This is indicated through SINGLE.LIMIT.DEFLT
Field . The value set here will be defaulted to SINGLE. LIMITFIELD in
ACCOUNT, for the new account opened satisfying the group condition. If
SINGLE.LIMIT.FIELD in account is defaulted to "Y" then only one account is
allowed to utilize the limit. If set to "N" then multiple accounts can utilize the same
limit.
When ever there are changes in interest rate, the rate change advices could be sent
to the customer by setting RATE.CHANGE.ADVICE Field as Yes . Message type
for such advice is entered in ADVICE.TYPE Field, with a valid record in
EB.ADVICES table.
45
It is possible to indicate transactions, which if done more than the threshold times
in a statement period, would constitute a violation. The violation could be set up as
not eligible for credit interest.
For example: Cash withdrawal transaction happening 10 or more times, within a
statement period of 1 month, then account not eligible for credit interest. Further, it
should also be considered as a violation.
TXN.THRESHOLD Field is used to define the threshold for each transaction code
or group in the TXN.CODE.GRP Field. If the number of qualifying transactions
equals or exceeds this threshold then the account will be deemed to have broken the
conditions for the waiving of credit interest and/or violation status as specified in
the related WAIVE.CR.INT and NO.VIOLATION Fields. This threshold applies to
each statement period.
NO.VIOLATION Field allows the related transaction threshold set, not to be used
for calculating account violations. When set as Yes, then the transactions in this
group will be recorded on the AC.VIOLATION record for the account with the
TXN.STATUS set to null and therefore will not influence the VIOLATION.STATUS
of the account. RETENTION.PERIOD Field decides how long this record should be
in live status.
46
The application INFO.ACCT.DR may be used to calculate Debit Interest and

interest related charges on-line up to a given date for a specific Account. Function
'V' is used to request the calculation, function 'S' allows the results of calculations to
be viewed. No bookkeeping entries are generated by this application. All details
contained in this file are for information only.
DB.INT.CALC.RND Field is used to indicate the type of rounding to apply to
individual credit interest calculations which is the amount stored in the
DR.INT.AMT Field of either INFO.ACCT.DR, ACCR.ACCT.DR or
STMT.ACCT.DR. CR.INT.CALC.RND Field specifies the type of rounding to
apply to individual credit interest calculations, i.e. the amount stored in the
CR.INT.AMT Field of either INFO.ACCT.CR, ACCR.ACCT.CR or
STMT.ACCT.CR.
DB.INT.TOT.RND indicates the type of rounding to apply to the total amount of
debit interest, i.e. the amount stored in the TOTAL.INTEREST Field of either
INFO.ACCT.DR, ACCR.ACCT.DR or STMT.ACCT.DR and CR.INT.TOT.RND
indicates the type of rounding to apply to the total amount of credit interest, i.e. the
amount stored in the TOTAL.INTEREST Field of either INFO.ACCT.CR,
ACCR.ACCT.CR or STMT.ACCT.CR.
Value entered should be a valid record in EB.ROUNDING.RULE table. This will
determine the type of rounding to be applied to the calculated interest amount.
Natural rounding relevant to interest currency is default.
47
48
49
50
Accounts that need to have the same statement generation frequency are grouped
together. For example DAILY frequency may be set up for current accounts of
private individuals residing in USA. It could also be for all current accounts of all
Corporates.
FREQUENCY.TYPE Field identifies whether the statement due date is to be
according to the anniversary of the opening date of the account or the period end
date.
For period end date, the end date depends upon the key of the record.
Monthly - Calendar end date of the month.
Quarterly - Calendar end date for the end of March, June, September or December.
Six Monthly - Calendar end date for the end of June or December.
Yearly - Calendar end date for the end of December.
If set as ANNIVERSARY, statement are produced on the same day on which the
account was opened . If the account was opened on 15th, then statement would be
produced on 15th of every month under monthly option and 15th of every quarter
under quarterly option.
51
52
53
It is possible to control the display of account number. ACCOUNT.MASK Field

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

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

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

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

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

CURRENCY are mandatory. Currency in which the account is opened is specified
by the ISO code of the currency and is validated with the setup in the static table,
CURRENCY. Currency of an account cannot be changed after authorisation.
JOINT.HOLDER.ID field records details of another customer as a joint holder of
the account. It is possible to multi value the field and add one or more joint account
holders. JOINT.RELATION.CODE field is used to indicate the relation between the
account holder and joint account holder. Main account holder can be replaced only
with a joint holder, any time later. Product code defines the type of the account like
savings, current, Nostro, Vostro etc. Category code should be in the range of 1000
and 9999 for all customer type of account. Product codes can be changed
subsequent to the opening of the account. For example a current account of a
customer can be changed into a savings account without closing the account.
Customer Id or Mnemonic can be used to indicate the Customer of an account.
While opening an Account, Currency and product codes could be either chosen
from the drop down list or can be made to be default automatically through suitably
designed versions. Account can be accessed in other applications by using either the
ID, or MNEMONIC or ALT.ACCT.ID.
ALT.ACCT.ID refers to the structure of an alternative account numbers. In practice
where ever T24 has replaced a legacy system it may be for a short term requirement
to allow access to the customers account using the old numbers
59
60
61
62
63
64
Account Search enquiries provide the list of accounts based on selection criteria.
Todays Account Balance enquiry has the option of giving either the customer or
account number and we can drill down to view the accounting entries for the day,
entries since last statement date and also projected forward movements in the
account.
Average Account Balance enquiry for a given period can be generated . It provides
account wise debit and credit balances. Entries for Today enquiry details the
accounting entries for the day. We can drill down to look into individual
transactions. Entries for the Given dates enquiry provides the accounting entries for
a given date for an account.
Balance on Statement Date enquiry provides the gist of statement for an account.
We can view the entries for a given account from the last statement date. Details of
the interest rate changes made in an account can be displayed though the Interest
Rate changes for Account enquiry. We can enquire the details of the locked account
under various dates and also the charges that are unpaid for an account by selecting
criteria account.
Further other enquires are available for viewing primary and joint accounts,
Inactive accounts, details of credit and debit interest posted, credit and debit interest
accrued and credit and debit interest corrected.
65
66
It is possible to manage different steps involved in cheque issue management. The

first step involves managing stock. This is common for bankers cheque , drafts ,
fixed deposit receipts and credit cards as well as cheques to be issued to customer
accounts.
As for cheques, it is possible to record receipt of stock, receiving requests for
cheque books from customers, sending cheques for further local printing and actual
issue to customers.
Cheques can be reordered manually using the application. If the automatic option is
chosen, during 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. This record can be followed , for automatic
delivery of cheque books to customers as a re-order process. It is possible to
charge customers while issuing cheque books which could be in addition to charges
to be applied on usage of cheques and a periodic charge for possession of cheques.
When a cheque book is issued to customers, range of cheque numbers will be
recorded into a cheque register. 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 table. On completion of the above transaction the cheque
register and CHEQUES.PRESENTED table is updated with the last status on the
cheque.
67
68
69
70
71
72
73
74
75
76
Image Management is used in conjunction with Graphical User Interface and gives
the ability to capture images and allows display of images, opening of document
files, media files and other files by their associated applications.
IM benefits user by providing immediate access to digital copies of essential data
such as signatures, passports, loan documentation, photos or birth certificates.
There is no need to access physical document itself. This may not be possible with
items such as passports, or if the item itself is stored somewhere for safekeeping.
Images can be displayed within the browser interface itself, whilst other file types
are shown as hyperlinks which can be used to open an associated application to
display the file. Automatic view of signature is possible in FT and Teller
applications through context sensitive enquiry. On the other hand if the images are
not linked to applications they can be viewed through enquiry.
To capture the images , only capture station needs access to a scanner. Others can
view stored images.
77
First settings to be made are to define the types or categories of files and images.
IM.IMAGE.TYPE record is used to record location of files and allows
categorisation of files by types which makes storage and retrieval to be setup in a
logical fashion. Customer photograph could be defined as one type, passport scans
as another and signatures as yet another. Images of particular type should be stored
in directory on the PC or network as defined by the combination of default drive
and path fields. Directory should be defined within webapps directory of Browser
setup.
So a typical usage would be to place similar types together in special directories, so
records such as PHOTO, PASSPORT, SECURITY, SIGNATURE, VIDEO, FORMS
etc would each have their own unique sub-directory.
Individual images are captured using IM.DOCUMENT.IMAGE application and
stored in the place indicated in IM.IMAGE.TYPE table. For example signature for
Account 100970 is captured. When the account is accessed by clicking on image
display icon image can be viewed.
78
IM.DOCUMENT.IMAGE application is used to define and store individual images.

If an image is to be related to a T24 applications like CUSTOMER or ACCOUNT,
then IMAGE.APPLICATION Field should indicate the same. If application like
account has been related, then image can be viewed whenever that account is
accessed. Otherwise the images can be accessed through enquiry.
IMAGE.REFERENCE contains a value relating to the stored image. It can be a
record key referred to by the IMAGE.APPLICATION or any valid field reference
like account number, Customer Id. After authorising the record, images are captured
in browser through IM.DOCUMENT.UPLOAD.
This application allows great flexibility in defining images as there is no restriction
on the type of application or field to which the stored image is related.
79
80
Sweep could be one way sweep from one or more designated accounts to another
specified accounts.
Maintenance is a standard Sweep to maintain balance. When balance in accounts
fall below a specified minimum amount, it sweeps funds from designated accounts
to maintain balance.
Surplus Sweep is return Sweep. When balance in accounts go above a specified
maximum, it sweeps excess funds to designated accounts .
Sweep could be two way also. Money can flow from `From account to `To account
if balance in To account is below a threshold amount and in addition, from `To
account to `From Account in case balance in `To account is above a specified
amount.
Two-way or Sweep and Return Sweep is a Maintenance and a Return Sweep in one
link. Maintenance Sweep always goes first.
Cash flow sweep is similar to the Two-way, but the total amounts that can be
requested are subject to user defined amount.
Sweep could be optionally made subject to posting restriction or defying posting
restriction.
Sweep could be triggered either without availing overdraft limit in an account or
otherwise.
81
Account Sweeping is a mechanism for creating automatic payments across a

number of Customer Accounts during COB , based on account balance reaching a
predefined Trigger amount. Different types of account sweeps are defined in
AC.SWEEP.TYPE. ID of AC.SWEEP.TYPE is alpha numeric. Alternatively a
routine to calculate sweep amount can be optionally attached in
AMT.SWEEP.ROUTINE Field. 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 AC.ACCOUNT.LINK for sweeping funds between accounts.
Sweep can be set to happen from a single account to many accounts and also from
many accounts to single account. Sweeping happens at the Close of business during
SYSTEM.END.OF.DAY2 in a job called AC.EOD.ACCOUNT.SWEEP. Resulting
movements are stored in AC.ACCOUNT.SWEEP.HIST.
82
AC. SWEEP.TYPE has four options namely Maintenance, Surplus, Two way and
Cash flow.
Maintenance is a standard Sweep for maintenance of balance. When the balance in
accounts falls below a specified minimum amount, it sweeps funds from designated
accounts to maintain balance.
Surplus Sweep or Return Sweep style involves sweeping funds when balance in
accounts go above a specified maximum value.
Surplus is the only sweep that supports handling of back valued entries.
Two-way is a combination of sweep and Return Sweep. This sweep style is simply a
Maintenance Sweep and a Return Sweep in one link. In this Case, the Maintenance
Sweep has priority and always goes first.
Cash flow is similar to Two-way sweep.
Similar to the Two-way except that the total amounts that can be requested are
subject to a user defined limit.
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.
From account can never be brought below its minimum amount.
It is possible to specify whether the amount calculated by T24 is passed to the
user defined routine mentioned in AC.SWEEP.TYPE for additional criteria to
arrive at the final sweep amount. When the RTN.WITH.SW.AMT Field is set to
YES after attaching the local routine, then the sweep amount calculated by T24 is
passed to the user routine.
83
While sweeping funds from one account to another account, there is a facility to
enable the sweeping mechanism to take from overdraft account. Overdraft limits
which are attached to an account could be used or sweep effected based on credit
balance in the account. Accordingly USE.LIMITS can be set as YES or No If this
field is set to YES then the limit attached to the overdraft account will be checked.
If it set as NO then it will disregard any limit in the overdraft account.
For example An account with a minimum balance of USD 200 and a Limit of USD
100 would trigger when the balance in the account becomes USD 100.
For return sweeps the funds will always go into the first account in the
ACCOUNT.FROM Field in AC.ACCOUNT.LINK. However, by setting the
PRIOROTISE.OD Field as YES in AC.SWEEP.TYPE, we 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 USD 200 and the second USD 50, the sweep would place USD 50 in
the second account and USD 150 in the first.
BALANCE.TO.USE Field is used to specify which type of balance is to be used for
sweep purposes. This could be Online actual, Online cleared or Working balance.
Online cleared balance includes values of all authorised entries over the Account
except any credit or reversal of debit entries with future exposure dates. Working
balance is value of cleared balances and unauthorised debit entries over the account.
Actual balance is cleared balance and credit entries with future exposure dates.
84
There could be posting restrictions on accounts and at customer level

RESTRICT.SWEEP Field if set to YES, sweep process would be stopped
depending on the following conditions .
1. When a POSTING.RESTRICT whose RESTRICTION.TYPE is ALL or DEBIT
is attached to the CUSTOMER whose ACCOUNT is to be debited or to the debit
ACCOUNT, then the sweep process, would be stopped.
2. When a POSTING.RESTRICT whose RESTRICTION.TYPE is ALL or
CREDIT is attached to the CUSTOMER whose ACCOUNT is to be credited or to
the credit ACCOUNT itself in a sweep process, then the sweep would be stopped.
3. When a ACCOUNT which is debited or credited in a Sweep process is attached
to a SEC.ACC.MASTER record which is blocked, then the Sweep would be
stopped from the date specified as BLOCKING.DATE.
4. If DEBIT.RESTRICT Field is set to YES in the ACCT.GROUP.CONDITION
record of an Account which is to be debited in a sweep process, then it would be
stopped.
Whenever a sweep process is stopped due to any of the above referred conditions,
the details would be written to the file AC.ACCOUNT.LINK.ERROR during batch
processing. SWEEP will be processed in spite of the above referred restrictions , if
this field is set to NO or NULL. In that case, relative STMT.ENTRY records will
contain all the overrides generated during sweep process.
85
AC.ACCOUNT.LINK application is used to create a link between accounts for

sweeping. Style of sweep is defined by SWEEP.TYPE and there must be a valid
record on AC.SWEEP.TYPE It should fall under one of the standard 4 sweep styles
such as maintenance, surplus, Two way and cash flow. Relevant rules, such as
minimum or maximum balance can be specified. These then define the value the
account needs to pass to trigger the sweep functionality. Accounts will be linked
through this table. It will allow multiple to and from accounts to be linked from
across multi company environments.
Frequency of sweep like BSNSS, ( Business days ) WEEK1, ( weekly ) M0101,
(monthly) M0331 ( Quarterly) is defined in FREQUENCY Field.
Sweeps are carried out during the COB process. ACCOUNT.FROM and
ACCOUNT.TO are multi value fields. Minimum and Maximum amounts for
beneficiary account trigger a sweep. 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.
For example, if Account 1 has a balance of USD 120 and a trigger to sweep when
the balance drops below USD 100 dollars. If USD 40 is debited from the account,
the resulting USD 80 balance will trigger the sweep as the balance has fallen below
the minimum.
86
87
88
89
90
91
92
We have come to the end of the session relating to ACCOUNT and other related
applications . We have seen the dependencies and linkages between account
module and T24 Core and other applications and also main business features of the
Account module.
We have also seen other related modules closely associated with customer type of
accounts like cheque, Account sweep and Image management
93
94

Accounts

Загружено:

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

Оригинальное название

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

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

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

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

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

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

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

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

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

Accounts

Загружено:

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

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

T3IMBR - Accounts - R9.

ACCOUNT application caters to creation and maintenance of all types of accounts

T3IMBR - Accounts - R9.01

T3IMBR - Accounts - R9.01

It is possible to set preferential service conditions for maintenance of accounts. The

T3IMBR - Accounts - R9.01

T3IMBR - Accounts - R9.01

T3IMBR - Accounts - R9.01

CONDITION.PRIORITY table is used to define criteria like nationality, industry ,

T3IMBR - Accounts - R9.01

In CONDITION.PRIORITY , you can rank the proposed selection criteria and

T3IMBR - Accounts - R9.01

T3IMBR - Accounts - R9.01

T3IMBR - Accounts - R9.01

T3IMBR - Accounts - R9.01

Lay out of ACCT.GEN.CONDITION and STMT.GEN.CONDITION is dependent

T3IMBR - Accounts - R9.01

Purpose of ACCT.GEN.CONDITION table is to define rules for grouping together

T3IMBR - Accounts - R9.01

Purpose of GROUP.CAPITALISATION table is to specify the next capitalisation

T3IMBR - Accounts - R9.01

It is possible to set different frequencies for interest capitalisation for Credit ,

T3IMBR - Accounts - R9.01

T3IMBR - Accounts - R9.01

T3IMBR - Accounts - R9.01

T3IMBR - Accounts - R9.01

T3IMBR - Accounts - R9.01

T3IMBR - Accounts - R9.01

INTEREST.DAY.BASIS gets its default value from respective CURRENCY table

T3IMBR - Accounts - R9.01

T3IMBR - Accounts - R9.01

If a minimum amount of interest is to be collected from an account, then it is

T3IMBR - Accounts - R9.01

T3IMBR - Accounts - R9.01

T3IMBR - Accounts - R9.01

T3IMBR - Accounts - R9.01

T3IMBR - Accounts - R9.01

T3IMBR - Accounts - R9.01

Minimum balance in account for interest calculation can be specified in

T3IMBR - Accounts - R9.01

T3IMBR - Accounts - R9.01

T3IMBR - Accounts - R9.01

T3IMBR - Accounts - R9.01

T3IMBR - Accounts - R9.01

The GENERAL.CHARGE record applicable to a particular Account is specified in

T3IMBR - Accounts - R9.01

In case of Foreign currency accounts, Account maintenance charges other than

T3IMBR - Accounts - R9.01

It is possible to selectively apply the charges set through

T3IMBR - Accounts - R9.01

WAIVE.CHARGE.NEG.BAL Field specifies whether all charges specified in

T3IMBR - Accounts - R9.01

It is possible to combine all charges except TRANSACTION.CHARGE and apply

T3IMBR - Accounts - R9.01

T3IMBR - Accounts - R9.01

Purpose of the ACCOUNT ACCRUAL table is to provide the system with

T3IMBR - Accounts - R9.01

It is possible to control the statement entries appearing in the customer statement.

T3IMBR - Accounts - R9.01

The accrual frequency can be DAILY, MONTHLY or it could be specified that no

T3IMBR - Accounts - R9.01

T3IMBR - Accounts - R9.01

Operational restrictions on maximum increase , allowing debits, minimum and