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.
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
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.
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.
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
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
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.
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
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.
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
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.
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.
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.
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.
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.
It is possible to set preferential service conditions for maintenance of accounts. The conditions are related to various activities which happen during the lifecycle of an account . Preferential conditions may be set for interest, charges, other tariff structure, accrual, and statements production. Groups are determined based on the selected elements from CUSTOMER and ACCOUNT record. The priority data items from customer and accounts are defined in the CONDITION.PRIORITY table for the record ACCOUNT.
Conditions for the calculation and application of interest and charges may be specified at the group level. If an account needs to be set up with different service conditions from the group to which it belongs, the group conditions are overridden with special conditions set for individual account level. When ever an account is opened, it is linked to the appropriate group based on the details of underlying Customer and nature of account. There must always be a default group created for accounts.
Basic elements for interest and charges calculation required are – (1) when capitalisation is done and (2) at what frequency it is done. This is required separately for Debit interest and Credit interest as they can differ.
Interest type that is used in the calculation i.e. fixed or floating are set up currency wise. Interest rates may be set up as level or banded interest rates with the effective dates . T24 provides the flexibility to calculate interest based on daily, average or minimum balance available for credit interest calculation in the account. Similarly it is possible to set debit interest based on daily, average or maximum balance .
It is possible to set up different type of interest related and ledger fees related charges. Interest should be defined with effective dates and for each currency. Interest rates can be set up as fixed or floating. Rate with level and banded structure. Balance on which interest is calculated can be specified as daily or average or minimum for credit interest & maximum for debit interest.
The set up of interest and charges grouping for Accounts structure starts with CONDITION.PRIORITY table. T24 permits us to decide the order of priority to apply criteria for creating groups for differential treatment.
Based on the priority and criteria chosen in CONDITION.PRIORITY, the actual fields are created in ACCT.GEN.CONDITION. Rules and values to criteria, when specified in this table, will group account records when opened into appropriate groups. It is mandatory that a default group with no conditions should be setup before we go on to create conditions attached groups.
Based on these groupings, Capitalisation rules, debit interest conditions and credit interest conditions for each group need to be setup in
GROUP.CAPITALISATION, GROUP.DEBIT.INT and GROUP.CREDIT.INT. If needed, account specific rules for all or some of the above 3 can be defined in ACCT.CAPITALISATION, ACCOUNT.DEBIT.INT and
ACCOUNT.CREDIT.INT files.
Charges related setup is done in related files and linked to
GENERAL.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.
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.
CONDITION.PRIORITY table is used to define criteria like nationality, industry , sector etc available in the CUSTOMER application and product category, currency from the ACCOUNT application.
For example, groups could be saving account of residents , saving account of non residents , current account of corporates engaged in software industry and current account of private citizens of US nationality. In these examples, criteria used are residence , nationality , industry and sector from
CUSTOMER application and savings and current accounts from ACCOUNT application.
Separate rules should be setup for interest and charges and statement purposes with record Id in CONDITION.PRIORITY as ACCOUNT and STATEMENT respectively. If company wise rules are required to be set up then the record Id of CONDITION.PRIORITY is suffixed with a “-” (hyphen) and company code namely ACCOUNT-company code and STATEMENT-company code. Else the data items will default from ACCOUNT and STATEMENT record Ids .
For example: If separate rules for interest and charges are required for a company GB0010001 and GB0010002, then two records with ids ACCOUNT.GB0010001 and ACCOUNT.GB0010002 are required.
If 3 companies setup with defaulting rules different only for third company namely GB0010003, then 2 records namely ACCOUNT and
ACCOUNT-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
The selection criteria for preference groups can be amended along with or without change in the ranking conditions. Dated CONDITION.PRIORITY records are required to be created to achieve this. The effective date could be either processing date or future date.
Id will be of the format ACCOUNT--<DATE>. The value in the middle field of Id can be used for company specific definition. Based on the previous selection criteria, general and group specific conditions would have been built. As a result of the new selection criteria there would be a need to re-define rules for some or all of the groups.
While defining CONDITION.PRIORITY records applicable in future , it is possible to specify which ACCT.GEN.CONDITION and
ACCT.GROUP.CONDITION records need to be retained by specifying their Ids in GEN.COND.KEEP and GROUP.COND.KEEP Fields.
During COB processing on the specified date, these ACCT.GEN.CONDITION records would be automatically modified with priority data items applicable for the new structure, existing priority data items and their values will be retained...New priority items will be updated with null values.
Advised to leave GEN.COND.KEEP as null so that old records are removed and new ones redefined. GROUP.COND.KEEP can also be set as ALL to retain all existing records.
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
Gen condition record, would be dropped after the COB processing.
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
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.
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.
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.
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.
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.
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%.
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.
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.
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.
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.
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
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 .
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.
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
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
