Accounts R12.01

T24 Accounts - T3TAC - R11.1

1

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

T24 Accounts - T3TAC - R11.1

2

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

T24 Accounts - T3TAC - R11.1

3

instructions.

By linking to another related module called image management, it is possible to verify signature of account holders. ACCOUNT module has a separate application called ACCOUNT.CLOSURE for closing accounts. Sweeping of balances between accounts can also be handled. A separate course is available for Account sweep and cash pooling. All the transactional balances and data are held on the EB.CONTRACT.BALANCES record for the account.

T24 Accounts - T3TAC - R11.1

3

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

T24 Accounts - T3TAC - R11.1

4

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

T24 Accounts - T3TAC - R11.1

5

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

T24 Accounts - T3TAC - R11.1

6

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

T24 Accounts - T3TAC - R11.1

6

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

7

charge period through IC.CHARGE.PRODUCT.

T24 Accounts - T3TAC - R11.1

7

These are the currency related static tables used by ACCOUNT application. COUNTRY table is used to record static details of each individual Country, for example, Country Name, Currency Code, etc.

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

T24 Accounts - T3TAC - R11.1

8

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

T24 Accounts - T3TAC - R11.1

9

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

T24 Accounts - T3TAC - R11.1

9

T24 Accounts - T3TAC - R11.1

10

T24 Accounts - T3TAC - R11.1

11

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

T24 Accounts - T3TAC - R11.1

12

GENERAL.CHARGE table.

T24 Accounts - T3TAC - R11.1

12

GROUP.CAPITALISATION table is used to specify the next date and subsequent frequency of capitalisation of debit and credit interest, for a group of Accounts.

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

T24 Accounts - T3TAC - R11.1

13

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

T24 Accounts - T3TAC - R11.1

14

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

T24 Accounts - T3TAC - R11.1

15

T24 Accounts - T3TAC - R11.1

16

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

T24 Accounts - T3TAC - R11.1

17

Basic elements for interest and charges calculation required are – (1) when capitalisation is done and (2) at what frequency it is done. This is required separately for Debit interest and Credit interest as they can differ.

Interest type that is used in the calculation i.e. fixed or floating are set up currency wise. Interest rates may be set up as level or banded interest rates with the effective dates . T24 provides the flexibility to calculate interest based on daily, average or minimum balance available for credit interest calculation in the account. Similarly it is possible to set debit interest based on daily, average or maximum balance . It is possible to set up different type of interest related and ledger fees related charges. Interest should be defined with effective dates and for each currency. Interest rates can be set up as fixed or floating. Rate with level and banded structure. Balance on which interest is calculated can be specified as daily or average or minimum for credit interest & maximum for debit interest.

T24 Accounts - T3TAC - R11.1

18

T24 Accounts - T3TAC - R11.1

19

The set up of interest and charges grouping for Accounts structure starts with CONDITION.PRIORITY table. T24 permits us to decide the order of priority to apply criteria for creating groups for differential treatment.

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

T24 Accounts - T3TAC - R11.1

20

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

T24 Accounts - T3TAC - R11.1

21

CONDITION.PRIORITY table is used to define criteria like nationality, industry , sector etc available in the CUSTOMER application and product category, currency from the ACCOUNT application.

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

22

In CONDITION.PRIORITY , you can rank the proposed selection criteria and indicate the applications from where the data is to be chosen. Allowed applications are ACCOUNT and CUSTOMER. Any single value or local reference fields from these applications can be chosen for making the selection criteria. PRIORITY.ITEM is a multi value Field which defines the file and field from that file used for criteria definition. The format is APPLICATION>FIELD.NAME. For example, in the CONDITION.PRIORITY record for ACCOUNT, the PRIORITY.ITEM field with ACCOUNT>CATEGORY implies that CATEGORY Field from the application ACCOUNT is an element of criteria. PRTY.VALIDATION Field indicates details of validation to be displayed as enrichment for the group definition. For example: In the above when field is set as “CATEGORY>DESCRIPTION”, then for a value entered in ACCT.GEN.CONDITION , System validates with CATEGORY table and DESCRIPTION in that CATEGORY record would be displayed as an enrichment. The order in which PRIORITY.ITEM is defined in the multi value set determines the priority of the item. For example : PRIORITY.ITEM.1 and PRIORITY.ITEM.2 when defined as ACCOUNT>CATEGORY and CUSTOMER>SECTOR implies that Category from Account is of higher priority than the other.

T24 Accounts - T3TAC - R11.1

23

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

T24 Accounts - T3TAC - R11.1

24

T24 Accounts - T3TAC - R11.1

25

T24 Accounts - T3TAC - R11.1

26

Lay out of ACCT.GEN.CONDITION and STMT.GEN.CONDITION is dependent on the settings made in CONDITION.PRIORITY for ACCOUNT and STATEMENT, respectively.

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

T24 Accounts - T3TAC - R11.1

27

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

T24 Accounts - T3TAC - R11.1

27

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

T24 Accounts - T3TAC - R11.1

28

.

T24 Accounts - T3TAC - R11.1

28

T24 Accounts - T3TAC - R11.1

29

T24 Accounts - T3TAC - R11.1

30

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

T24 Accounts - T3TAC - R11.1

31

T24 Accounts - T3TAC - R11.1

32

T24 Accounts - T3TAC - R11.1

33

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

T24 Accounts - T3TAC - R11.1

34

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

T24 Accounts - T3TAC - R11.1

35

T24 Accounts - T3TAC - R11.1

36

T24 Accounts - T3TAC - R11.1

37

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

T24 Accounts - T3TAC - R11.1

38

INTEREST.DAY.BASIS gets its default value from respective CURRENCY table . If it is to be different, then it is possible to indicate the same. If debit interest need not be calculated, then NONE to be indicated.

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

T24 Accounts - T3TAC - R11.1

39

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

T24 Accounts - T3TAC - R11.1

40

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

T24 Accounts - T3TAC - R11.1

41

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

T24 Accounts - T3TAC - R11.1

42

T24 Accounts - T3TAC - R11.1

43

T24 Accounts - T3TAC - R11.1

44

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

It is possible to net debit interest against credit interest prior to calculating tax , if both are capitalised on the same dates. DR interest can be netted against CR interest and DR2 interest can be netted against CR2 interest.

T24 Accounts - T3TAC - R11.1

45

Similar to the features in GROUP.DEBIT.INT, it is possible to set rules for first and second credit interest as fixed and/ or floating interest rate. The rates could be on a level or band basis. Similarly, it is possible to waive or pay a minimum amount of interest. CR.MAX.RATE Field is used to define the capped rate for credit balance type. If the rate that is derived after applying any spread, is more than this rate then interest rate will be capped at this value. Credit Interest can be calculated on daily, average or minimum balance during the interest period by defining in CR.BALANCE.TYPE Field. If “MINIMUM” is opted , the minimum balance during a period within a month is used for interest calculations. It is possible to set negative interest rates on accounts in credit. To achieve this , NEGATIVE.RATES Field on GROUP.CREDIT.INT must be set to YES. If this field is set as either “No” or left unpopulated, then when interest rates fall below 0, zero interest will be accrued to that account. If set to YES, this would enable collecting interest from accounts even though they have credit balances.

Negative interest rates may occur by CR.BASIC.RATE being specified with a discount , such that the net effective rate is negative. This is useful for penalising overdraft accounts maintaining credit balance. If set to BLOCK.MARGIN, negative effect will not be allowed because of margin. Negative margin can not make the rate more negative or a positive rate to negative. For Example, If base rate is -7, margin is -2 then net effect will be -7.If margin is +2 then the effective rate become -5. If base rate is +5 and margin is -7 then effective rate will be zero not negative.

T24 Accounts - T3TAC - R11.1

46

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

T24 Accounts - T3TAC - R11.1

47

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

T24 Accounts - T3TAC - R11.1

48

T24 Accounts - T3TAC - R11.1

49

T24 Accounts - T3TAC - R11.1

50

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

T24 Accounts - T3TAC - R11.1

51

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

T24 Accounts - T3TAC - R11.1

52

specifically mentioned for that currency.

T24 Accounts - T3TAC - R11.1

52

T24 Accounts - T3TAC - R11.1

53

T24 Accounts - T3TAC - R11.1

54

T24 Accounts - T3TAC - R11.1

55

GOVERNMENT.MARGIN is a table used to define supplementary flat percentage charge calculated on overdraft balances by the system on capitalisation date and collected on behalf of the Government. The same percentage charge is applicable for all currencies. It is possible to specify Minimum and Maximum Amounts for specific currencies as well as default minimum and maximum local currency equivalent amounts which apply to all other currencies. If there are no overdraft balances during the Capitalisation period, no Government Margin charge is made. The Government Margin rate ruling on the date of the debit interest capitalisation is applicable for the whole Capitalisation period. The purpose of INTEREST.STATEMENT table is to specify a flat fee which is levied at the time of production of a Debit Interest Statement. Specific charges can be entered by currency. For all currencies not specifically mentioned, a default charge can be entered in local currency equivalent.

It is possible to have up to 99 records for all the charges discussed. Id comprises numeric suffixed with month and year. These records are attached to GENERAL.CHARGE and linked to GROUP.DEBIT.INT. For each of these charges, profit and loss category and transaction codes are required to be defined.

T24 Accounts - T3TAC - R11.1

56

T24 Accounts - T3TAC - R11.1

57

T24 Accounts - T3TAC - R11.1

58

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

T24 Accounts - T3TAC - R11.1

59

T24 Accounts - T3TAC - R11.1

60

T24 Accounts - T3TAC - R11.1

61

T24 Accounts - T3TAC - R11.1

62

Similar to credit transactions charges may be set for debit transactions. NUMBER.OF.DEBIT table may be used to specify a fixed charge per entry for debit transactions which pass over an Account during Capitalisation period.

Alternatively, TURNOVER.DEBIT table is used to specify a percentage charge on the total value of chargeable debit entries which pass over an Account during the Capitalisation period. Entries are chargeable only for those records in TRANSACTION table which are defined Y in TURNOVER.CHARGE Field. Only one of these two types of charges can be specified for each Account. Charge amount , free amount ,minimum and maximum amounts can be specified for each currency. Default amounts in local currency equivalent may also be defined and is used for accounts in currencies for which no amounts are specified separately.

T24 Accounts - T3TAC - R11.1

63

T24 Accounts - T3TAC - R11.1

64

T24 Accounts - T3TAC - R11.1

65

T24 Accounts - T3TAC - R11.1

66

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

T24 Accounts - T3TAC - R11.1

67

T24 Accounts - T3TAC - R11.1

68

T24 Accounts - T3TAC - R11.1

69

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

T24 Accounts - T3TAC - R11.1

70

with or without details currency wise.

T24 Accounts - T3TAC - R11.1

70

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

T24 Accounts - T3TAC - R11.1

71

T24 Accounts - T3TAC - R11.1

72

T24 Accounts - T3TAC - R11.1

73

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

T24 Accounts - T3TAC - R11.1

74

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

T24 Accounts - T3TAC - R11.1

75

In case of Foreign currency accounts, Account maintenance charges other than TRANSACTION. CHARGE can be collected or waived by using the option of Yes or No in CHARGE.OF.FCY.ACCT Field.

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

T24 Accounts - T3TAC - R11.1

76

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

T24 Accounts - T3TAC - R11.1

77

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

T24 Accounts - T3TAC - R11.1

78

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

T24 Accounts - T3TAC - R11.1

79

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

Details for waiving charges and calculating offsets for Accounts, in specific Currencies may be specified in the multi value group of associated OFFSET.CURRENCY, MIN.AV.BAL, DAY.BASIS, BAL.NO.OFFSET and LOW.AMT.CHARGE Fields. PERCT.FOR.OFFSET Field is used to indicate the rate. DEFAULT. DAY.BASIS or DAY.BASIS are used to indicate the interest day basis to be used in the calculation.

T24 Accounts - T3TAC - R11.1

80

T24 Accounts - T3TAC - R11.1

80

T24 Accounts - T3TAC - R11.1

81

T24 Accounts - T3TAC - R11.1

82

T24 Accounts - T3TAC - R11.1

83

T24 Accounts - T3TAC - R11.1

84

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

T24 Accounts - T3TAC - R11.1

85

T24 Accounts - T3TAC - R11.1

86

T24 Accounts - T3TAC - R11.1

87

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

Currently, MTH.END.UPTO.DAY Field can only be set as 31. When interest capitalisation for an Account is also set as 31, month end accrual processing and application will both take place on the last working day of every month.

T24 Accounts - T3TAC - R11.1

88

It is possible to control the statement entries appearing in the customer statement. APP.POSTING.DAY Field specifies whether interest is to appear on a customer statement on the date it is calculated or on the following day.

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

T24 Accounts - T3TAC - R11.1

89

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

T24 Accounts - T3TAC - R11.1

90

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

T24 Accounts - T3TAC - R11.1

91

T24 Accounts - T3TAC - R11.1

92

T24 Accounts - T3TAC - R11.1

93

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

T24 Accounts - T3TAC - R11.1

94

application.

T24 Accounts - T3TAC - R11.1

94

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

T24 Accounts - T3TAC - R11.1

95

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

T24 Accounts - T3TAC - R11.1

95

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

T24 Accounts - T3TAC - R11.1

96

It is possible to indicate transactions, which if done more than the threshold times in a statement period, would constitute a violation. The violation could be set up as not eligible for credit interest.

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

T24 Accounts - T3TAC - R11.1

97

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

T24 Accounts - T3TAC - R11.1

98

T24 Accounts - T3TAC - R11.1

99

T24 Accounts - T3TAC - R11.1

100

T24 Accounts - T3TAC - R11.1

101

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

T24 Accounts - T3TAC - R11.1

102

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

T24 Accounts - T3TAC - R11.1

103

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

T24 Accounts - T3TAC - R11.1

104

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

T24 Accounts - T3TAC - R11.1

105

T24 Accounts - T3TAC - R11.1

106

There are three dates in accounting entries. Booking date is System date when transaction entry is generated. The date used is from TODAY Field in DATES table for the Company being processed.

Value date is the date from which entry is to be given effect for interest purposes. This is not used for entries affecting Internal Accounts. If Value date is not entered in the originating transaction, or not defaulted from application level rules or TRANSACTION table, the value date is assumed to be the same as the Booking date. Exposure date is the date on which the proceeds of a cheque or other credits can be drawn against . This date can be different from value date and transaction date. This date can only be present in Credit entries or Debit entries which are reversals of Credit entries. If the Exposure date is not entered in the originating transaction, or not defaulted from application level rules or TRANSACTION table, it is assumed to be the same as Booking date. Please note that the exposure date does not affect interest calculation as the value date is relevant for that.

T24 Accounts - T3TAC - R11.1

107

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

Cleared balance includes values of all authorised entries over the Account except any credit or reversal of debit entries with future exposure dates. Working balance is value of cleared balances and unauthorised debit entries over the account. Working balance is useful for checking of limits attached to an Account. Actual balance is cleared balance and credit entries with future exposure dates.

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

T24 Accounts - T3TAC - R11.1

108

date or exposure date.

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

T24 Accounts - T3TAC - R11.1

108

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

T24 Accounts - T3TAC - R11.1

109

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

T24 Accounts - T3TAC - R11.1

110

AVAILABLE.BAL.UPD Field identifies how the available balance of account in ECB should be updated. This is top level setup which can be overruled at ACCOUNT or ACCT.GROUP.CONDITION (if ACCOUNT is blank).

The options include BOTH where unauthorised debits and credits to be included in the available balance , NONE when no unauthorised movements to be included in the available balance field found in ECB. When DEBITS is chosen only unauthorised debits to make up available balance and for CREDITS only unauthorised credits to make up available balance The default will be none when only authorised movements are to be included in the available balance. EXPOSURE.DATE.AF Field is used to indicate the choice for setting up the available funds ladder .Yes or Null is used to indicate funds ladder to be updated on the basis of exposure date. No to indicate funds ladder updated on value date.

T24 Accounts - T3TAC - R11.1

111

CREDIT.CHECK identifies on which balance, overdraft and limit checking should be made for all accounts. Default is Working balance field found in ECB.

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

T24 Accounts - T3TAC - R11.1

112

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

T24 Accounts - T3TAC - R11.1

112

Sometimes there is need to keep balance information for reporting purpose as contingent. It is possible by opening Contingent Accounts. This facility is available for both customer and internal accounts. This contingent account processing is used to calculate interest on a customer Limit unutilised and/or utilised. T24 monitors the limit record and any charges in the unutilised and or utilised amount are posted to the contingent accounts by way of entries. For this processing an internal contingent account is used as the other side of each entry. Interest can be calculated on the customer contingent account. CONT.DESC, CONT.CAT.STR and CONT.CAT.END Fields are used to indicate contingent account and range of category codes. T24 has facility to change the product code without closing an account. For example a savings account can be converted as current account without closing the savings account. However, a Nostro account category can be replaced only by another Nostro category.

A customer of an account can be replaced only with the joint account holder and not by any other customer. The joint holder can also be amended subsequently. The main advantage is, after observing the operations in an account, it is possible to upgrade / downgrade it to another type of account with different service conditions. ACCT.CATEG.DESC Field is used to have a description for the account category range defined in ACCT.CATEG.STR and ACCT.CATEG.END Fields for customer replacement .

T24 Accounts - T3TAC - R11.1

113

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

T24 Accounts - T3TAC - R11.1

114

account was opened then CHARGE.FIRST.MONTH Field must be set to YES.

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

T24 Accounts - T3TAC - R11.1

114

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

T24 Accounts - T3TAC - R11.1

115

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

T24 Accounts - T3TAC - R11.1

116

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

T24 Accounts - T3TAC - R11.1

116

T24 Accounts - T3TAC - R11.1

117

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

T24 Accounts - T3TAC - R11.1

118

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

T24 Accounts - T3TAC - R11.1

119

T24 Accounts - T3TAC - R11.1

120

T24 Accounts - T3TAC - R11.1

121

The purpose of POSTING.RESTRICT table is to define various type of restrictions which may be imposed on Accounts, For example 'POST NO DEBITS', 'WHEREABOUTS UNKNOWN', 'PENDING CLOSURE', etc.

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

T24 Accounts - T3TAC - R11.1

122

automatically.

T24 Accounts - T3TAC - R11.1

122

The order in which these files should be created is stored within the automated tool for system build. For easy reference, the order sequence in is in ascending build reference order as listed in the left.

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

T24 Accounts - T3TAC - R11.1

123

This diagram shows the dependencies of accounts application on various other tables which are categorised as either customer related, interest related, statement related, processing related and the internal tables.

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

T24 Accounts - T3TAC - R11.1

124

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

We have already seen parameter tables for setting up rules regarding calculation and capitalisation of interest and charges. CONDITION.PRIORITY allows us to decide the order of priority and the priority items (attributes) based on which rules for creating account groups. Based on the priority items defined in CONDITION.PRIORITY, different account groups are created in ACCT.GEN.CONDITION including a default group which is used when no criteria for grouping is set up. When an account is opened, based on a specific criteria defined, T24 will automatically assign a group for the Account. Based on these grouping conditions, the following are setup for each group: 1. Capitalisation rules 2. Debit interest conditions 3. Credit interest details These are setup in GROUP.CAPITALISATION, GROUP.DEBIT.INT and GROUP.CREDIT.INT. While the interest conditions are set up at the currency level for a group, the capitalisation will be set up at group levels. If required, account specific rules can also be setup for all or some of the above T24 Accounts - T3TAC - R11.1

125

three functionalities. They are defined in ACCT.CAPITALISATION, ACCOUNT.DEBIT.INT and ACCOUNT.CREDIT.INT tables. Apart from these, various type of interest related and account maintenance related charges are set up and linked to GENERAL.CHARGE. The GENERAL.CHARGE records are further attached to GROUP. DEBIT. INT or ACCOUNT.DEBIT.INT for collection of charges from the underlying accounts. A mandatory “default” record for default charges is required in GENERAL.CHARGE. When we talk about GENERAL.CHARGE, we must understand that charges fall into 2 types, those that are levied at the same time as debit interest is applied (Interest Related Charges) and those which are considered to be fees for maintenance of an Account (Ledger Fee Charges). DEBIT.INT.ADDON, GOVERNMENT.MARGIN, HIGHEST.DEBIT Charge and INTEREST.STATEMENT are the Interest related charges and the others are the maintenance related charges. These are defined in separate tables and the ID is further attached to the GENERAL.CHARGE table.

T24 Accounts - T3TAC - R11.1

125

Having discussed about the parameter tables and the interest and charges related tables, let us also learn about the tables used for account statement generation. When a new Account is opened, an Account Statement record, specifying the date and frequency for printing Account statements, is generated automatically by the system which may be subsequently amended manually, if required. The purpose of the STMT.GEN.CONDITION is to define rules for determining the default statement frequency when opening new Accounts.

T24 Accounts - T3TAC - R11.1

126

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

T24 Accounts - T3TAC - R11.1

127

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

T24 Accounts - T3TAC - R11.1

128

T24 Accounts - T3TAC - R11.1

129

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

T24 Accounts - T3TAC - R11.1

130

liabilities such as suspense account, cash account etc.

T24 Accounts - T3TAC - R11.1

130

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

T24 Accounts - T3TAC - R11.1

131

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

T24 Accounts - T3TAC - R11.1

132

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

T24 Accounts - T3TAC - R11.1

133

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

T24 Accounts - T3TAC - R11.1

133

T24 Accounts - T3TAC - R11.1

134

T24 Accounts - T3TAC - R11.1

135

T24 Accounts - T3TAC - R11.1

136

T24 Accounts - T3TAC - R11.1

137

T24 Accounts - T3TAC - R11.1

138

T24 Accounts - T3TAC - R11.1

139

T24 Accounts - T3TAC - R11.1

140

T24 Accounts - T3TAC - R11.1

141

T24 Accounts - T3TAC - R11.1

142

T24 Accounts - T3TAC - R11.1

143

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

T24 Accounts - T3TAC - R11.1

144

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

T24 Accounts - T3TAC - R11.1

145

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

T24 Accounts - T3TAC - R11.1

146

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

T24 Accounts - T3TAC - R11.1

147

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

T24 Accounts - T3TAC - R11.1

148

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

T24 Accounts - T3TAC - R11.1

148

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

T24 Accounts - T3TAC - R11.1

149

If Available date is greater or equal to date of the worst locked Amount then the shortfall on that date is compared to the one from current Balance check and an override is raised if the shortfall is worse.

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

Override ‘AVAIL.LIMIT.LOCKED.EXPIRING’ to indicate that the Limit is expiring.

T24 Accounts - T3TAC - R11.1

150

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

T24 Accounts - T3TAC - R11.1

151

It is possible to link a overdraft to one account or more than one account. If SINGLE.LIMIT Field in ACCOUNT is set to “Y” then only one account can be attached to a limit record. If this is set to “N” or Null, multiple accounts can be attached to a limit. The combined total all debit account balances resulting in an overdraft should not exceed the sanctioned limit. SINGLE.LIMIT Field should be set as Y/N. It can be defaulted from ACCT.GROUP.CONDITION using SINGLE.LIMIT.DEFLT Field. SINGLE.LIMIT in account can also be used independently without setting up ACCT.GROUP.CONDITION. For certain types of limit product it is possible to net credit account balances and debit account balances found in ECB. If an account with a credit balance is to be included in the limit checking, the ALLOW.NETTING Field should be set to YES. In this instance the total of credit and debit balances will be netted. Default value is No, then the debit balances of accounts will be totaled together, without adjusting for any credit balances, for limit checking

T24 Accounts - T3TAC - R11.1

152

purposes.

T24 Accounts - T3TAC - R11.1

152

T24 Accounts - T3TAC - R11.1

153

T24 Accounts - T3TAC - R11.1

154

T24 Accounts - T3TAC - R11.1

155

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

T24 Accounts - T3TAC - R11.1

156

The balance related fields of Account are available in ECB. Credit check is made whenever a debit transaction is validated or is validated and authorised at the same time. An option is available to set credit checking for an account against working balance and cash flows or available balance via the CREDIT.CHECK Field in ACCOUNT.PARAMETER. The available choices are AVAILABLE when credit checking is made using AVAILABLE.BAL, or WORKING when credit checking is made using WORKING.BALANCE, or FORWARD when credit checking is made using WORKING.BALANCE plus today's forward movements, or AVAILWORK when credit checking is made using AVAILABLE.BAL and WORKING.BALANCE, or AVAILFWD when credit checking is made using AVAILABLE.BAL and WORKING.BALANCE plus today's forward movements, or BLANK when the default checking is using WORKING.BALANCE

AVAILABLE.BAL always includes authorised debits and credits. Parameterisation regarding the update of available balances with unauthorised entries takes place as follows via AVAILABLE.BAL.UPD. BOTH make unauthorised debits and credits to make up available balance NONE means no unauthorised movements to update available balance. DEBITS will use only unauthorised debits to make up available balance. CREDITS will use only unauthorised credits to make up available balance. It will be selected in the

T24 Accounts - T3TAC - R11.1

157

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

T24 Accounts - T3TAC - R11.1

157

T3TFA - Financial Accounting - R10.2

158

We can observe that the cashflow Days field is now setup for 5 days with Available balance updates for unauthorised Debits

T24 Accounts - T3TAC - R11.1

159

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

T24 Accounts - T3TAC - R11.1

160

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

T24 Accounts - T3TAC - R11.1

161

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

T24 Accounts - T3TAC - R11.1

162

In screenshot 1 -We can see the ECB record of the account with available balance ladder for unauthorised LD Loan maturity for $5000 and unauthorised LD Deposit drawndown for $1000 In screenshot 2 Upon authorisation of LD deposit, we can find the available balance getting updated for LD deposit maturity as well In screenshot 3 Upon authorisation of LD deposit, we can find the available balance getting updated for LD loan liquidation on the start date of the loan

T24 Accounts - T3TAC - R11.1

163

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

T24 Accounts - T3TAC - R11.1

164

T24 Accounts - T3TAC - R11.1

165

We can find the Account parameter record has got a credit check field update for working balance.

T24 Accounts - T3TAC - R11.1

166

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

T24 Accounts - T3TAC - R11.1

167

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

T24 Accounts - T3TAC - R11.1

168

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

T24 Accounts - T3TAC - R11.1

169

limit.

T24 Accounts - T3TAC - R11.1

169

T24 Accounts - T3TAC - R11.1

170

T24 Accounts - T3TAC - R11.1

171

T24 Accounts - T3TAC - R11.1

172

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

173

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

T24 Accounts - T3TAC - R11.1

173

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

T24 Accounts - T3TAC - R11.1

174

T24 Accounts - T3TAC - R11.1

175

T24 Accounts - T3TAC - R11.1

176

T24 Accounts - T3TAC - R11.1

177

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

T24 Accounts - T3TAC - R11.1

178

T24 Accounts - T3TAC - R11.1

178

It is possible to issue passbooks if the rules in the record SAVINGS in ACCOUNT.CLASS is met and PASSBOOK Field is set as YES for an Account.

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

T24 Accounts - T3TAC - R11.1

179

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

T24 Accounts - T3TAC - R11.1

180

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

T24 Accounts - T3TAC - R11.1

181

T24 Accounts - T3TAC - R11.1

182

T24 Accounts - T3TAC - R11.1

183

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

T24 Accounts - T3TAC - R11.1

184

handled by the Account Closure routine .

T24 Accounts - T3TAC - R11.1

184

T24 Accounts - T3TAC - R11.1

185

T24 Accounts - T3TAC - R11.1

186

T24 Accounts - T3TAC - R11.1

187

T24 Accounts - T3TAC - R11.1

188

T24 Accounts - T3TAC - R11.1

189

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

T24 Accounts - T3TAC - R11.1

190

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

T24 Accounts - T3TAC - R11.1

191

STATUS Field indicates current status of charge request. STATUS Field is set to PAID if accounting entries are required, as this is the status that generates the entries. Four status options are available.

PAID - Charges paid and accounting entries to be raised. TAKEN - Account entries for the charge have been raised via another application. UNPAID - Awaiting payment. A request has been made, but no further action has been taken. Status could be subsequently changed to any other status with suitable change in CHARGE.DATE Field. WOF - If the charge request is refused. When the STATUS is UNPAID, the transaction will stay on the live file indefinitely. All other status will put the transaction to the history file during the Close of Business process.

Request type of CHARGE or BOOK along with Status of PAID will raise accounting entries. While CHARGE will create delivery message and BOOK without delivery message.

T24 Accounts - T3TAC - R11.1

192

T24 Accounts - T3TAC - R11.1

193

T24 Accounts - T3TAC - R11.1

194

T24 Accounts - T3TAC - R11.1

195

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

T24 Accounts - T3TAC - R11.1

196

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

T24 Accounts - T3TAC - R11.1

196

Account charges are not calculated for the month in which the Account is closed, unless the closure date is the last day of month. It is possible to specify any predefined charges for closing account.

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

T24 Accounts - T3TAC - R11.1

197

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

T24 Accounts - T3TAC - R11.1

197

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

T24 Accounts - T3TAC - R11.1

198

T24 Accounts - T3TAC - R11.1

199

T24 Accounts - T3TAC - R11.1

200

T24 Accounts - T3TAC - R11.1

201

In this workshop, let us book a FT with future value date between two T24 accounts. Then, try to close the account without authorising that FT. Please observe the error thrown.

T24 Accounts - T3TAC - R11.1

202

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

T24 Accounts - T3TAC - R11.1

203

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

T24 Accounts - T3TAC - R11.1

204

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

T24 Accounts - T3TAC - R11.1

205

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

Currency Market, Suspense Category, Terminal Number, Account Officer (P&L only) Product Category (P&L only),Plus any additional elements defined in AC.CONSOLIDATE.COND. Through ADD.CONSOL.FLD, Field we can include additional STMT / CATEG entry Fields to be used in consolidation of entries. Field must be an

T24 Accounts - T3TAC - R11.1

206

existing name in STANDARD.SELECTION application.

T24 Accounts - T3TAC - R11.1

206

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

T24 Accounts - T3TAC - R11.1

207

Id for the table is alphanumeric and can be between 3 and 20 characters. When S option is chosen, non-F entries are consolidated value-date wise. F Statement entries will not be consolidated.

To consolidate F Statement entries also, the option F should be specified in addition to S. Selected EB.SYSTEM, TRANSACTION and CATEGORY codes and/or Routines can be excluded from consolidation. ADD.CONSOL.FLD Field can have values of additional STMT / CATEG.ENTRY data fields to be used in consolidation of entries.

T24 Accounts - T3TAC - R11.1

208

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

T24 Accounts - T3TAC - R11.1

209

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

A default record named CLDEFAULT exists for the consolidation process of entries on Customer accounts. The purpose is to start consolidating entries by default after the 50th statement entry raised for the day.

T24 Accounts - T3TAC - R11.1

210

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

CORR.ACCT.DR and CORR.ACCT.DR2 files contain details of the previous calculation of debit interest, which have been capitalised and recalculated and corrected. The new details are held on the STMT.ACCT.DR and STMT.ACCT.DR2 files. .

T24 Accounts - T3TAC - R11.1

211

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

T24 Accounts - T3TAC - R11.1

212

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

213

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

214

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

215

What types of accounts can use the high volume processing? Customer Accounts Nostro Accounts Internal Accounts The high volume processing is not yet available for AA Accounts. It is not possible to run credit checking with a high volume account.

216

The field HVT.FLAG in the account controls if an account is included in high volume processing. IF this is set to No or Null then the account is not included. If et to Yes then it is included. An account can be added to high volume processing or removed at any time by amending this field.

217

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

218

The existing account is marked with HVT flag as yes.

219

The new account is created with HVT flag marked as yes

220

Create two funds transfer records to credit one of the high volume accounts After booking the FT we can find the records updating AC.HVT.TRIGGER file

221

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

222

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

223

STMT.PRINTED is another file that is updated for high volume processing, multiple records will be created for high volume which will be merged when the service is run. The screen shots show the records created for the FT’s crediting account 66093891

224

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

225

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

226

Run the TSA.SERVICE BNK/AC.HVT.MERGE.SERVICE Then check the EB.CONTRACT.BALANCES record has been updated for the account and the underlying accounting files entries have been merged and the original entries removed.

227

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

228

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

229

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

230

T24 Accounts - T3TAC - R11.1

231

T24 Accounts - T3TAC - R11.1

232

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

T24 Accounts - T3TAC - R11.1

233

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

T24 Accounts - T3TAC - R11.1

234

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

T24 Accounts - T3TAC - R11.1

235

T24 Accounts - T3TAC - R11.1

236

T24 Accounts - T3TAC - R11.1

237

T24 Accounts - T3TAC - R11.1

238

T24 Accounts - T3TAC - R11.1

239

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

T24 Accounts - T3TAC - R11.1

240

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

T24 Accounts - T3TAC - R11.1

241

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

T24 Accounts - T3TAC - R11.1

242

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

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

T24 Accounts - T3TAC - R11.1

243

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

T24 Accounts - T3TAC - R11.1

244

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

T24 Accounts - T3TAC - R11.1

245

T24 Accounts - T3TAC - R11.1

246