Account T24

ACCOUNT
The Account Module caters for the creation, maintenance and control of all types of accounts handled by T24 It also provides:
- Calculation and application of interest on customers' accounts.
- Calculation of charges relating to the maintenance and servicing of accounts.
- Production of account statements and overdraft and referral reports.
Accounts can be classified as two types :
Customer Accounts
These include any accounts related to a customer and are identified by account numbers of up to 14 digits including the check digit. It is not possible to open a customer account until the relevant customer base record and group interest and charges conditions have been created.
In addition to the account number and the number of the customer base record to which the account relates, the record contains details such as: Currency, Category, Limit, Account Officer etc.. Customer details such as name, nationality, residence etc., are held in the customer base record and will be taken from
that record as and when required.
Internal Accounts
These include any accounts not related to a customer, such as cash, unremitted profits and capital. Since there is no customer base record related to Internal Accounts, details such as account title and short title need to be specified when the account is created.
Internal Accounts are identified by codes specifically structured to include information defining the account as follows:
- Currency - Category - Subdivision within the main category classification.
In an extended multi company environment where accounts owned by different companies (branches) share the same account file the internal account will have the subdivision code of the owning company appended to the account number, so the account number will be 16 characters.
To allow accurate and detailed MIS analysis, profit and loss data is not held in internal accounts, but is kept at the lowest level by use of specific category codes which are used by all Applications to record profit and loss entries.
The main features of the Account Module can be summarised as follows:
Posting Restrictions
Various types of restrictions may be defined, such as 'Post No Debits', 'Wehereabouts Unknown'. Entries meeting the specified conditions will prompt a message on the screen and will only be accepted with an override.
Referral
Special referral conditions can be defined depending on transaction details such as transaction code, amount and sign, or the balance of the account.
An end of day report is produced including details of transactions and balances for referral to the account officer.
Account Statements
Account statements show details of all entries over the account since the last statement. Entries are listed in transaction date sequence and may show both transaction date and value date.
Statements may be produced every working day, every 1-9 weeks, twice a month on the 15th and the last day or every 1-6 months on any day of the month.
Two statement cycles may be specified for each account, e.g. weekly and monthly. These cycles may be independent or combined:
- Independent : Statements for each cycle show details of all entries since the last statement in the same cycle, regardless of the other cycle.
- Combined : Statements are produced on the dates specified by both cycles, but only contain details of entries since the last statement from either cycle.
If there have been no entries since the last statement, the statement may be suppressed unless six months have elapsed.
Special interim statements, showing details of all entries since the last regular cycle 1 statement., may be produced any day without affecting the regular statement cycles.
Overdraft Report
This will show details of all accounts whose Limit is exceeded and any overdrawn accounts with no limit specified.
Group and Special Conditions
Conditions for the calculation and application of interest and charges are specified for groups of accounts and can be overridden with special conditions for individual accounts.
Account groups are determined automatically on the basis of customer and account details such as residence, sector, account category and currency. The criteria used and their order of priority are stored in user defined tables.
Interest Calculations
- Interest may be calculated on a Daily, Average, or Highest/ Minimum balance basis using value dated balances.
- The movements/balances on different accounts in the same currency can be combined and interest calculated on the net result.
- Rates can be fixed or linked to basic rates plus or minus a margin.
- Different rates can be specified for different balance levels and may be linked to the same or different basic rates. The rates may apply to the whole of the balance or to the part between two balance levels.
- Using group level conditions, it is possible to use the limits on individual accounts as the first level for debit interest so that one rate can be charged up to the limit on any account and another rate when the limit has been exceeded.
- Interest can be calculated on a 366/365, 366/360, 360/365 or 360/360 days basis.
- Back valued entries generate automatic adjustments to previously calculated interest. For any accounts where interest conditions or rates are changed with effect prior to the last interest application, the system generates adjustments on request.
Interest Application and Accrual
Dates
- Interest may be applied daily, every working day, every 1-9 weeks, twice a month on the 15th and the last day or every 1-99 months on any day of the month. The application dates can be specified at group or account level. Cycles may be different for debit and credit interest.
- Special interim applications may be requested without affecting the regular cycle.
- It is possible to accrue interest normally on a monthly basis and specify certain types of accounts with daily accrual.
Special Cases
- Interest may be paid or received from another account in the same currency.
- Credit interest may be calculated for the purpose of off-setting debit interest only and not for application. In this case debit and credit interest application dates must be the same.
- Interest may be suspended for specific accounts i.e. not posted to profit and loss.
- It is possible to calculate interest for information only and not accrue or apply it e.g. for Nostro accounts.
- Detailed interest statements may be printed for specified accounts whenever interest is applied.
Interest Related Charges
Tax on interest is calculated at application time.
Certain additional charges based on the debit interest application may be applied on the same date. These include:
- Debit Interest Addon - a percentage of the amount of debit interest to be applied.
- Government Margin - an additional interest rate applied to each debit interest calculation.
- Highest Debit - a percentage of the largest debit balance.
- Interest Statement - a charge for providing a detailed interest statement when debit interest is applied.
Account Maintenance Charges
Account Maintenance Charges may be levied monthly, quarterly or six monthly, always at the end of the appropriate month. The same Application cycle is used for all accounts. There are two main types of charges, as follows:
- Balance Requirement
A flat charge can be levied if a certain average or minimum balance is not maintained. A range of charges for different balances may be specified.
- Transaction Charges
Charges can be made for the transactions passed over an account. These may be based on the number or the volume of transactions and may be different for debit and credit or for each transaction type. Each transaction type may be included or excluded from the calculations. The various types of transaction
charges are as follows:
. Number of credit . Number of debit . Turnover credit . Turnover debit . Transaction type
Charges may be combined into one account entry or applied separately. Free, minimum and maximum amounts can be specified for each charge.
Separate charges can be defined for specific currencies and local currency charges used as the default for all non- specified currencies.
Offsetting and Waiving Charges
On specified accounts, charges may be calculated for information only and then waived.
Charges may also be waived if a certain average or minimum balance is maintained, if the amount of the charge is below a value worth charging or if the account has been into debit.
It is possible to specify that charges do not apply to foreign currency accounts.
Notional credit interest can be calculated and offset against the charges.
AC.TEST AC.TEST
ACC.DEB.LIMIT ACC.DEB.LIMIT
ACCOUNT.NUMBER
Multi valued to hold the account debit limit dates.
ACCOUNT.OFFICER
ACCOUNT.TITLE.1 Validation Rules:
ACCOUNT.TITLE.2 Standard date format. (Internal field updated during end of day processing.)
ACCOUNTING.COMPANY ACCOUNT.NUMBER
ACCR.CHG.AMOUNT Identifies the Account.
ACCR.CHG.CATEG
It is assumed that the format of Customer Account numbers will be changed to suit each installation, provisionally it must conform to the modulus 11 check i.e. the Account number and a check digit must be entered. The value of the check digit is calculated as shown below.
ACCR.CHG.SUSP
ACCR.CHG.TRANS To calculate the Modulus 11 check digit:
ACCR.CR.AMOUNT 1) Starting from the low order digit (right), each digit of the Account number has a weighting factor as shown below: 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 Digit No. X 4 3 2 7 6 5 4 3 2 7 6 5 4 3 2 Weighting Results: + + + + + + + + + + + + + + + = Y
ACCR.CR.CATEG 2) Each digit is multiplied by the appropriate weighting factor.
ACCR.CR.SUSP 3) All results are added and the total (Y) divided by eleven.
ACCR.CR.TRANS 4) Finally, the remainder from the division is subtracted from 11 to obtain the Check Digit.
ACCR.CR2.AMOUNT Note: If the calculated Check Digit is greater than 9, 3 is subtracted from it to obtain the correct Check Digit.
ACCR.CR2.CATEG Example: Account number chosen = 1024562
ACCR.CR2.SUSP
1 0 2 4 5 6 2 X 2 7 6 5 4 3 2 (Weighting Factors) Results: 2 + 0 + 12 + 20 + 20 + 18 + 4 = 76 76/11 = 6 Remainder 10
ACCR.CR2.TRANS
ACCR.DR.AMOUNT 11 - 10 = 1 = Check Digit Number to be entered = 10245621
ACCR.DR.CATEG Internal Account Numbers consist of a Currency Code, a Category Code and an identifying number, as follows:
ACCR.DR.SUSP (i) 3 type SSS (uppercase alpha) character Currency code or 'L', which will generate the Local Currency code.
ACCR.DR.TRANS (ii) 5 numeric character, Category code in the range 10000 to 19999.
ACCR.DR2.AMOUNT (iii) Up to 4 numeric character Sub Division code, which, if not input, will default to 1.
ACCR.DR2.CATEG Validation Rules:
ACCR.DR2.SUSP
2-14 numeric characters Customer Account number or 6-12 (16 in extended multi company) type SS (uppercase alpha or numeric, first character alpha) character Internal Account number (see Details)
ACCR.DR2.TRANS
ACCT.CREDIT.INT Mandatory input.
ACCT.DEBIT.INT ACCOUNT.OFFICER
ALL.IN.ONE.PRODUCT Identifies the main Account Officer responsible for the Account.
ALLOW.NETTING For Customer Accounts, this should be entered only when a different Officer from that held for the related Customer is required.
ALLOWED.BV.DATE Validation Rules:
ALT.ACCT.ID 1-4 numeric character Account Officer code. (Mandatory for Internal Accounts, otherwise optional input. The System will default to the Officer held for the related Customer although this will not be generated in this field.)
ALT.ACCT.TYPE
It must be an existing code on the DEPT.ACCT.OFFICER table (ref: General Tables).
AMNT.LAST.CR.AUTO
AMNT.LAST.CR.BANK Some applications automatically open Internal Accounts for their processing (eg. TELLER, LD etc). In such cases this field will contain either the Department code of the currently signed on USER (if the Internal Account is being created Online) or the Department code of the Internal first
AMNT.LAST.CR.CUST Internal Account to be found by the system in the same CATEGORY as this account (if the new Internal Account is being created during the End of Day).
AMNT.LAST.DR.AUTO ACCOUNT.TITLE.1
AMNT.LAST.DR.BANK Identifies the first part, or the whole, of the Account Title.
AMNT.LAST.DR.CUST This Field distinguishes individual Accounts, e.g. for a Customer who holds more than one Account. The title can be continued in the ACCOUNT TITLE 2 Field.
APR Multi-lingual field to hold the account title in different languages.
ARRANGEMENT.ID
Validation Rules:
AUTO.PAY.ACCT
AUTO.REC.CCY Up to 35 type A (alphanumeric) characters. (Mandatory for Internal Accounts, otherwise optional input. Default is the Short Name from the Customer record.)
AV.AUTH.CR.MVMT ACCOUNT.TITLE.2
AV.AUTH.DB.MVMT Continuation of Account Title 1.
AV.NAU.CR.MVMT Multi-lingual field to hold the account title in different languages.
AV.NAU.DB.MVMT Validation Rules:
AVAILABLE.BAL Up to 35 type A (alphanumeric) characters. (Optional input. No default value.)
AVAILABLE.BAL.UPD
AVAILABLE.DATE ACCOUNTING.COMPANY
BALANCE.CONVERSION.MKT Holds the accounting company of the account record. This company ID will be determined based on AU rules.
BUNDLE.ARRANGEMENT Only set when accounting companies are linked to the normal T24 business company
CAP.BACK.VALUE This field will be enabled to input only if AU product is installed in the company
CAP.DATE
Validation Rules:
CAP.DATE.C2.INT
CAP.DATE.CHARGE Must be a valid company record with consolidation mark set as 'A'
CAP.DATE.CR.INT ACCR.CHG.AMOUNT
CAP.DATE.D2.INT Amount of Account Charges (ledger fees) on this Account which have been calculated and accrued, (booked to Profit and Loss), but have not yet been capitalised (booked to the Customer's Account).
CAP.DATE.DR.INT Validation Rules:
CAP.DATE.PRM Standard amount format. Multivalue field associated with Fields ACCR.CHG.CATEG to ACCR.CHG.SUSP. (Internal field updated during end of day processing.)
CASH.POOL.GROUP
ACCR.CHG.CATEG
CATEGORY
CHARGE.ACCOUNT Profit and Loss Category code for Account Charges (ledger fees) on this Account which have been calculated and accrued, (booked to Profit and Loss), but have not yet been capitalised (booked to the Customer's Account or another Liquidation Account).
CHARGE.CCY This field is also used when there are values outstanding in the ACCR.CHG.SUSP field which have been capitalised.
CHARGE.MKT Validation Rules:
CLOSED.ONLINE 5 numeric characters Category code. Multivalue field associated with fields ACCR.CHG.TRANS to ACCR.CHG.SUSP. (Internal field updated during end of day processing.)
CLOSURE.DATE ACCR.CHG.SUSP
CLOSURE.NOTES
Amount of Account Charges (ledger fees) on this Account which have been calculated and held in suspense instead of being accrued (booked to Profit and Loss). This happens when the Interest No Booking flag in the Account record is set to SUSPENSE, e.g. in cases of bad and doubtful debts.
CLOSURE.REASON
CON.CHARGE.ACCR Validation Rules:
CON.INTEREST.ACCR Standard amount format. Multivalue field associated with fields ACCR.CHG.CATEG to ACCR.CHG.SUSP. (Internal field updated during end of day processing.)
CONDITION.GROUP ACCR.CHG.TRANS
CONSOL.KEY Transaction code for Account Charges (ledger fees) on this Account which have been calculated and accrued, (booked to Profit and Loss), but have not yet been capitalised (booked to the Customer's Account).
CONSOLIDATE.ENT Validation Rules:
CONTINGENT.BAL.CR 1-10(Max Value) numeric characters Transaction Code.
CONTINGENT.BAL.DR
The Maximum value is specified in EB.OBJECT for TRANSACTION.
CONTINGENT.INT
CR.ADJ.AMOUNT Multivalue field associated with fields ACCR.CHG.CATEG to ACCR.CHG.SUSP. (Internal field updated during end of day processing.)
CR2.ADJ.AMOUNT ACCR.CR.AMOUNT
CREDIT.CHECK Amount of Credit Interest on this Account which has been calculated and accrued, (booked to Profit and Loss), but has not yet been capitalised (booked to the Customer's Account).
CREDIT.CHK.CONDITION Validation Rules:
CREDIT.CHK.TXN.TYPE Standard amount format. Multivalue field associated with fields ACCR.CR.CATEG to ACCR.CR.SUSP. (Internal field updated during end of day processing.)
CREDIT.MOVEMENT
CURRENCY ACCR.CR.CATEG
CURRENCY.MARKET Profit and Loss Category code for Credit Interest on this Account which has been calculated and accrued, (booked to Profit and Loss), but has not yet been capitalised (booked to the Customer's Account or another Liquidation Account).
CUSTOMER This field is also used when there are values outstanding in the ACCR.CR.SUSP field which have been capitalised.
CUSTOMER.CODE Validation Rules:
CUSTOMER.MNEMONIC 5 numeric characters Category code. Multivalue field associated with fields ACCR.CR.TRANS to ACCR.CR.SUSP. (Internal field updated during end of day processing.)
DATE.LAST.CR.AUTO ACCR.CR.SUSP
DATE.LAST.CR.BANK
Amount of Credit Interest on this Account which has been calculated and held in suspense instead of being accrued (booked to Profit and Loss). This happens when the Interest No Booking flag in the Account record is set to SUSPENSE, e.g. in cases of bad and doubtful debts.
DATE.LAST.CR.CUST
DATE.LAST.DR.AUTO Validation Rules:
DATE.LAST.DR.BANK Standard amount format. Multivalue field associated with fields ACCR.CR.CATEG to ACCR.CR.AMOUNT. (Internal field updated during end of day processing.)
DATE.LAST.DR.CUST ACCR.CR.TRANS
DATE.LAST.UPDATE Transaction code for Credit Interest on this Account which has been calculated and accrued, (booked to Profit and Loss), but has not yet been capitalised (booked to the Customer's Account).
DEBIT.MOVEMENT Validation Rules:
DISPO.EXEMPT
1-10(Max Value) numeric characters Transaction Code.
DISPO.OFFICER
DR.ADJ.AMOUNT The Maximum value is specified in EB.OBJECT for TRANSACTION.
DR2.ADJ.AMOUNT Multivalue field associated with fields ACCR.CR.CATEG to ACCR.CR.SUSP. (Internal field updated during end of day processing.)
EMERGENCY.BLOCK ACCR.CR2.AMOUNT
EMERGENCY.REASON Amount of 2nd type of Credit Interest on this Account which has been calculated and accrued, (booked to Profit and Loss), but has not yet been capitalised (booked to the Customer's Account).
END.DATE Validation Rules:
ENTRY.HOLD Standard amount format. Multivalue field associated with fields ACCR.CR2.CATEG to ACCR.CR2.SUSP. (Internal field updated during end of day processing.)
EP.BALANCE
ER.BALANCE ACCR.CR2.CATEG
ER.VALUE.DATE Profit and Loss Category code for 2nd type of Credit Interest on this Account which has been calculated and accrued, (booked to Profit and Loss), but has not yet been capitalised (booked to the Customer's Account or another Liquidation Account).
EVENT This field is also used when there are values outstanding in the ACCR.CR2.SUSP field which have been capitalised.
EXPOSURE.DATES Validation Rules:
EXTERNAL.POSTING 5 numeric characters Category code. Multivalue field associated with Fields 61 to 63. (Internal field updated during end of day processing.)
FA.STATUS
ACCR.CR2.SUSP
FIELD
FIRST.AF.DATE Amount of 2nd type of Credit Interest on this Account which has been calculated and held in suspense instead of being accrued (booked to Profit and Loss). This happens when the Interest No Booking flag in the Account record is set to SUSPENSE, e.g. in cases of bad and doubtful debts.
FORWARD.MVMTS Validation Rules:
FROM.DATE Standard amount format. Multivalue field associated with fields ACCR.CR2.CATEG to ACCR.CR2.AMOUNT. (Internal field updated during end of day processing.)
FWD.ENTRY.HOLD ACCR.CR2.TRANS
HVT.FLAG Transaction code for 2nd type of Credit Interest on this Account which has been calculated and accrued, (booked to Profit and Loss), but has not yet been capitalised (booked to the Customer's Account).
IC.CHARGE.ID Validation Rules:
IC.LST.PROD.CAP
IC.NEXT.CAP.DATE
IC.PRODUCT The Maximum value is specified in EB.OBJECT for TRANSACTION.
ICA.ADD.REMOVE Multivalue field associated with Fields ACCR.CR2.CATEG to ACCR.CR2.SUSP. (Internal field updated during end of day processing.)
ICA.BACK.VALUE ACCR.DR.AMOUNT
ICA.DISTRIB.RATIO Amount of Debit Interest on this Account which has been calculated and accrued, (booked to Profit and Loss), but has not yet been capitalised (booked to the Customer's Account).
ICA.DISTRIB.TYPE Validation Rules:
ICA.MAIN.ACCOUNT
Standard amount format. Multivalue field associated with fields ACCR.DR.CATEG to ACCR.DR.SUSP. (Internal field updated during end of day processing.)
ICA.MAIN.ACCT
ICA.MAIN.ACCT.IND ACCR.DR.CATEG
ICA.MAIN.DATE Profit and Loss Category code for Debit Interest on this Account which has been calculated and accrued, (booked to Profit and Loss), but has not yet been capitalised (booked to the Customer's Account or another Liquidation Account).
ICA.MAIN.RATIO This field is also used when there are values outstanding in the ACCR.DR.SUSP field which have been capitalised.
ICA.NEW.MAIN.ACC Validation Rules:
ICA.POST.INTEREST 5 numeric characters Category code. Multivalue field associated with fields ACCR.DR.TRANS to ACCR.DR.SUSP. (Internal field updated during end of day processing.)
ICA.START.DATE
ACCR.DR.SUSP
INACTIV.MARKER
INT.LIQ.CCY Amount of Debit Interest on this Account which has been calculated and held in suspense instead of being accrued (booked to Profit and Loss). This happens when the Interest No Booking flag in the Account record is set to SUSPENSE, e.g. in cases of bad and doubtful debts.
INT.LIQU.ACCT Validation Rules:
INT.LIQU.TYPE Standard amount format. Multivalue field associated with fields ACCR.DR.CATEG to ACCR.DR.AMOUNT. (Internal field updated during end of day processing.)
INT.NO.BOOKING ACCR.DR.TRANS
INTEREST.CCY Transaction code for Debit Interest on this Account which has been calculated and accrued, (booked to Profit and Loss), but has not yet been capitalised (booked to the Customer's Account).
INTEREST.COMP.ACCT
Validation Rules:
INTEREST.LIQU.ACCT
INTEREST.MKT 1-10(Max Value) numeric characters Transaction Code.
JOINT.HOLDER The Maximum value is specified in EB.OBJECT for TRANSACTION.
JOINT.NOTES Multivalue field associated with fields ACCR.DR.CATEG to ACCR.DR.SUSP. (Internal field updated during end of day processing.)
LAST.COM.CHG.DATE ACCR.DR2.AMOUNT
LEDG.RECO.WITH Amount of 2nd type of Debit Interest on this Account which has been calculated and accrued, (booked to Profit and Loss), but has not yet been capitalised (booked to the Customer's Account).
LIMIT.KEY Validation Rules:
LIMIT.PROC.TYPE
Standard amount format. Multivalue field associated with fields ACCR.DR2.CATEG to ACCR.DR2.SUSP. (Internal field updated during end of day processing.)
LIMIT.REF
LINK.TO.LIMIT ACCR.DR2.CATEG
LIQUIDATION.MODE Profit and Loss Category code for 2nd type of Debit Interest on this Account which has been calculated and accrued, (booked to Profit and Loss), but has not yet been capitalised (booked to the Customer's Account or another Liquidation Account).
LOCK.INC.THIS.MVMT This field is also used when there are values outstanding in the ACCR.DR2.SUSP field which have been capitalised.
LOCKED.AMOUNT Validation Rules:
LOCKED.WITH.LIMIT 5 numeric characters Category code. Multivalue field associated with fields ACCR.DR2.TRANS to ACCR.DR2.SUSP. (Internal field updated during end of day processing.)
LONG.POS.SIGN
MANDATE.APPL ACCR.DR2.SUSP
MANDATE.RECORD Amount of 2nd type of Debit Interest on this Account which has been calculated and held in suspense instead of being accrued (booked to Profit and Loss). This happens when the Interest No Booking flag in the Account record is set to SUSPENSE, e.g. in cases of bad and doubtful debts.
MANDATE.REG Validation Rules:
MASTER.ACCOUNT Standard amount format. Multivalue field associated with fields ACCR.DR2.CATEG to ACCR.DR2.AMOUNT. (Internal field updated during end of day processing.)
MAX.SUB.ACCOUNT ACCR.DR2.TRANS
MERGE.NCU Transaction code for 2nd type of Debit Interest on this Account which has been calculated and accrued, (booked to Profit and Loss), but has not yet been capitalised (booked to the Customer's Account).
MNEMONIC
Validation Rules:
MULTI.CURRENCY
MV.ALERT.RES1 1-10(Max Value) numeric characters Transaction Code.
MV.ALERT.RES2 The Maximum value is specified in EB.OBJECT for TRANSACTION.
MV.ALERT.RES3 Multivalue field associated with fields ACCR.DR2.CATEG to ACCR.DR2.SUSP. (Internal field updated during end of day processing.)
MV.ALERT.RES4 ACCT.CREDIT.INT
MV.ALERT.RES5 This is a multi valued field which will hold all account credit int dates.
MV.ALERT.RES6
NEXT.ACCT.CAP Validation Rules:
NEXT.AF.DATE Standard date format. (Internal field updated during end of day processing.)
NEXT.EXP.DATE ACCT.DEBIT.INT
NEXT.STMT.DATE This is a multi valued field which will hold all account debit int dates.
NOSTRO.CCY
ONLINE.ACTUAL.BAL Validation Rules:
ONLINE.CLEARED.BAL Standard date format. (Internal field updated during end of day processing.)
OPEN.ACTUAL.BAL ALL.IN.ONE.PRODUCT
OPEN.ASSET.TYPE Identifies the All in One Account Product, to which this account belongs. The value defined in AZ.ACCOUNT of the same ID is defaulted here.
OPEN.AVAILABLE.BAL
The Account and AZ account inherit the default features of the All in One product defined, like penal rate, Repayment type, Maximum Interest only period, etc.
OPEN.CATEGORY
OPEN.CLEARED.BAL Certain validations like minimum term, maximum term, allowed category, maximum back date, minimum and maximum amount (in the case of deposit) are done at the AZ account, with respect to the values defined under the corresponding All in One Product.
OPEN.VAL.DATED.BAL Validation Rules:
OPENING.DATE 1-9999 numeric, non negative.
OPERAND Should have been already defined under AZ.PRODUCT.PARAMETER and AZ.ACCOUNT
ORIG.CCY.PAYMENT No input Field
ORIGINAL.ACCT
OTHER.OFFICER ALLOW.NETTING
OUR.EXT.ACCT.NO This field will denote whether this account for this customer can allow netting for limits of both credit and debit balances.
OVERDUE.STATUS Validation Rules:
OVERRIDE Valid input is 'Yes' or 'No' (Optional input)
PARENT.ACCOUNT Default is 'No' (=Null)
PARENT.BV.DATE
ALLOWED.BV.DATE
PASSBOOK
PENDING.ID This field holds the latest restructuring date of the network of Parent accounts above this account. It will be set to the date when an account was added to the network of Parent accounts as either a direct or indirect parent of this account
PORTFOLIO.NO If the back value date of the Statement Entry is prior to this date then the Transaction will be rejected with an error message
POSITION.TYPE Validation Rules:
POSTING.RESTRICT Standard Date Format
PREMIUM.FREQ
ALT.ACCT.ID
PREMIUM.TYPE
PRINTING.CODE Allows maintenance of alternate account identifiers for any alternate account system defined in the T24 system. Any alternate account system identifiers will appear in the previous field.
RECO.TOLERANCE The account identifiers by which the user's T24 account is alternatively identified can be linked to the T24 account in this field.
RECONCILE.ACCT The ALTERNATE.ACCOUNT application within T24 is maintained by this field.
REDUCING.LIMIT Validation Rules:
REF.DATA.ITEM Multi-valued field.
REF.DATA.VALUE Optional input field.
REFERAL.CODE
Format is dependent on the definitions in the ALT.ACCT.PARAMETER application.
RELATION.CODE
REQUEST.ID Entries in this field will be validated in accordance with the rules defined for each alternate account system in the ALT.ACCT.PARAMETER application.
S.BUNDLEID ALT.ACCT.TYPE
S.DAYS In this application any alternate account systems defined in the ACCOUNT.PARAMETER application will be defaulted to allow maintenance of the alternate account system.
S.LINKTYPE When alternate account systems are defined in the ALT.ACT.PARAMETER application and entered in the ACCOUNT.PARAMETER ALTERNATE.ID field, their system identifiers will be displayed here, allowing maintenance of the alternate account identifiers in the following field.
S.SIMULATED.CCY Validation Rules:
SAM.ID.HIST No amendments are allowed.
SB.GROUP.ID
Multivalue field.
SECONDARY.LIMIT.AMT
SERIAL.NO.FORMAT This is a NOINPUT field.
SHADOW.ACCOUNT AMNT.LAST.CR.AUTO
SHORT.TITLE Contains the amount of the last automatically generated credit entry passed to this Account.
SHOW.TILL.ACS If more than one credit entry is generated automatically on the same day, details of the largest one are stored here.
SINGLE.LIMIT Validation Rules:
START.DATE
Standard amount format. (Internal field updated during end of day processing.)
START.YEAR.BAL
STMT.RECO.WITH AMNT.LAST.CR.BANK
STOCK.CONTROL.TYPE Contains the amount of the last bank generated credit entry passed to this Account.
TAX.AT.SETTLE If more than one credit entry is generated by the bank on the same day, details of the largest one are stored here.
TAX.SUSPEND Validation Rules:
TOTAL.PENDING Standard amount format. (Internal field updated during end of day processing.)
TRAN.LAST.CR.AUTO
AMNT.LAST.CR.CUST
TRAN.LAST.CR.BANK
TRAN.LAST.CR.CUST Contains the amount of the last Customer generated credit entry passed to this Account.
TRAN.LAST.DR.AUTO If more than one credit entry is generated by the Customer on the same day, details of the largest one are stored here.
TRAN.LAST.DR.BANK Validation Rules:
TRAN.LAST.DR.CUST Standard amount format. (Internal field updated during end of day processing.)
TX.BEN.NUM AMNT.LAST.DR.AUTO
TXN.AMT
Contains the amount of the last automatically generated debit entry passed to this Account.
TXN.CODE
VAL.DATE If more than one debit entry is generated automatically on the same day, details of the largest one are stored here.
VALUE Validation Rules:
VALUE.DATE Standard amount format. (Internal field updated during end of day processing.)
VALUE.DATED.BAL AMNT.LAST.DR.BANK
WAIVE.LEDGER.FEE Contains the amount of the last bank generated debit entry passed to this Account.
WORKING.BALANCE If more than one debit entry is generated by the bank on the same day, details of the largest one are stored here.
T24 Common HelpText
Validation Rules:
Fields
AMNT.LAST.DR.CUST
Contains the amount of the last Customer generated debit entry passed to this Account.
If more than one debit entry is generated by the customer on the same day, details of the largest one are stored here.
Validation Rules:
APR
This field stores the Annual Payment Rate (or the Taux Effectif Global in France).
Validation Rules:
1-10 type R (standard rate format) characters plus a decimal point.
This is a NOINPUT field.
ARRANGEMENT.ID
Holds the Arrangement record Key. Arrangement id that belong to corresponding portfolio or customer
Validation Rules
Should be a valid arrangement record ID.
No input
AUTO.PAY.ACCT
This is the account number to be used instead of the original account when attempting to pass accounting entries over the original account.
Validation Rules:
If the currency of the account specified here is different from the original account's currency then both the currencies must have a fixed rate specified for them.
Input only allowed if 'EU' is installed.
Can be an internal account.
CONTINGENT.INT should be of the same contingent type as the account.
AUTO.REC.CCY
This field is used to specify the entries with this currency for which diversion of accounting entries must take place. If this field is specified then the accounting routine will look for a customer-currency combination as an id in the file CUST.ACCT.CCY.REC to obtain the RECEIVE.ACCOUNT to
which the accounting entries will be diverted.
Validation Rules:
Must be a valid currency.
The currency must be linked by a fixed rate to this accounts currency.
AV.AUTH.CR.MVMT
Identifies the total authorised credit movements to the account with an exposure date specified by field AVAILABLE.DATE above.
This field is provided to show the authorised daily credit movements to accounts on the date specified in field AVAILABLE.DATE above.
Depending on the flag set in the AVAILABLE.BAL.UPD, this field, together with the AV.NAU.CR.MVMT field below, and fields AV.AUTH.DR.MVMT and
It is updated by all credit entries when they have been fully Authorised.
Validation Rules:
Standard Amount Format. (Internal field) This field forms a multi value set with fields from AVAILABLE.DATE to FORWARD.MVMTS.
AV.AUTH.DB.MVMT
Identifies the total authorised debit movements to the account valued on the date specified by field AVAILABLE.DATE above.
This field is provided to show the authorised daily debit movements to accounts on the date specified in field AVAILABLE.DATE above. Depending on the flag set in the AVAILABLE.BAL.UPD, this field, together with the AV.NAU.DB.MVMT, AV.AUTH.CR.MVMT,AV.NAU.CR.MVMT fields below, will be
used to make up the AVAILABLE.BAL, and is used for overdraft and limit checking.
It is updated by all debit entries when they have been fully Authorised.
Validation Rules:
AV.NAU.CR.MVMT
Identifies the total unauthorised credit movements to the account with an exposure date specified by field AVAILABLE.DATE above.
This field is provided to show the unauthorised daily credit movements to accounts on the date specified in field AVAILABLE.DATE above.
Depending on the flag set in the AVAILABLE.BAL.UPD, either this field or
It is updated by all credit entries that are still unauthorised, except if they have been restricted either at transaction level or application level in EB.AF.PARAM.
Validation Rules:
AV.NAU.DB.MVMT
Identifies the total unauthorised debit movements to the account with an value date specified by field AVAILABLE.DATE above.
This field is provided to show the unauthorised daily debit movements to accounts on the date specified in field AVAILABLE.DATE above.
Depending on the flag set in the AVAILABLE.BAL.UPD, either this field or
It is updated by all debit entries which are still unauthorised, except if they have been restricted either at transaction level or application level in
Validation Rules:
Standard Amount Format. (Internal field) This field forms a multi value set with fields from AVAILABLE.DATE FORWARD.MVMTS.
AVAILABLE.BAL
This field is the net of authorised debits and credits under fields AV.AUTH.DB.MVMT and AV.AUTH.CR.MVMT and plus the previous days AVAILABLE.BAL.
However, AV.NAU.DB.MVMT or AV.NAU.CR.MVMT may also be included in the Available balance depending on the flag set in the AVAILABLE.BAL.UPD:
BOTH: Unauthorised debits and credits to be included in the available balance
DEBITS: Only unauthorised debits to make up available balance
CREDITS: Only unauthorised credits to make up available balance
The Available balance is used for Overdraft and Limit checking if the CREDIT.CHECK field is set to AVAILABLE
This multi-valued field will display the respective available balances as a result of all future dated movements that fall within the cash flow window (as specified on the ACCOUNT.PARAMETER file field CASH.FLOW.DAYS).
Validation Rules:
Standard Amount Format. (internal Field) ,this field forms a multi value set with fields from AVAILABLE.DATE to FORWARD.MVMTS.
AVAILABLE.BAL.UPD
It identifies whether Unauthorised debits or Unauthorised credits , or both or none of them may be included in the available balance.
It will be selected in the following order:
1. ACCOUNT
2. ACCT.GROUP.CONDITION (if ACCOUNT is blank)
3. ACCOUNT.PARAMETER (if ACCT.GROUP.CONDITION is blank)
For example if nothing is set at ACCOUNT level then the ACCT.GROUP.CONDITION is checked and if still nothing is set at this level, the ACCOUNT.PARAMETER is checked.
Validation Rules:
BOTH: Unauthorised debits and credits to be included in the available balance
NONE: No unauthorised movements to be included in the available balance
DEBITS: Only unauthorised debits to make up available balance
CREDITS: Only unauthorised credits to make up available balance
The default will be No authorised movements to be included in the available balance
AVAILABLE.DATE
Contains the exposure date of future credit and the value date of future debit movements to the account for the purpose of available funds processing.
Fields AV.AUTH.DB.MVMT to AVAILABLE.BAL, indicate all debit movements to the account valued on the date in this field and all credit movements with that exposure date.
Any unauthorised entry that is not included in the movement has been restricted in EB.AF.PARAM through EB.AF.PARAM.CHANGE either at application level or at transaction level within an application.
Available Funds Balances are held here for all forward dated and value dated and forward exposure dated account movements up to the number of calendar days forward from today as specified on the 'CASH FLOW DAYS' field on the ACCOUNT.PARAMETER file.
If a real entry e.g. Funds Transfer, Data Capture (not a contract entry e.g. Money Market, Loans and Deposits), is made to the account for a value date or and exposure date that is beyond the cash flow window, then this value date or exposure date will replace the old window end date and all
available funds balances will be shown up to this new date.
Validation Rules:
Standard Date Format. (Internal Field) This field forms a multi value set with field AVAILABLE.DATE to FORWARD.MVMTS.
BALANCE.CONVERSION.MKT
This field holds the Currency Market to be used for merging balances in multi-currency accounts and Limit validations. If it is not entered the Currency Market of the account will be used
BUNDLE.ARRANGEMENT
Help Text for this field is unavailable. Please refer to the T24 User Guides for further information.
CAP.BACK.VALUE
If any entries with Value Dates earlier than the last Capitalisation Date for interest on this Account have been processed since the last interest Capitalisation, this field contains the Value Date of the earliest entry. This is used as the starting point for automatic interest adjustment.
This field is only used during end of day processing and is always blank during on line day time.
It is set by EOD.ACCT.ACTIVITY and cleared by EOD.CAPITALIS.CORR.
Validation Rules:
Standard date format. (Internal field updated during end of day processing.)
CAP.DATE
CAP.DATE.C2.INT
Contains the dates on which the 2nd type of Credit Interest for this Account has been applied (booked) to the Customer's Account or to another (Liquidation) Account.
Validation Rules:
Standard date format. Multivalue field. (Internal field updated during end of day processing.)
CAP.DATE.CHARGE
Contains the dates on which Account Charges (ledger fees) for this Account have been applied (booked) to the Customer's Account or to another (Liquidation) Account.
Validation Rules:
CAP.DATE.CR.INT
Contains the dates on which Credit Interest for this Account has been applied (booked) to the Customer's Account or to another (Liquidation) Account.
Validation Rules:
CAP.DATE.D2.INT
Contains the dates on which the 2nd type of Debit Interest for this Account has been applied (booked) to the Customer's Account or to another (Liquidation) Account.
Validation Rules:
CAP.DATE.DR.INT
Contains the dates on which Debit Interest for this Account has been applied (booked) to the Customer's Account or to another (Liquidation) Account.
Validation Rules:
CAP.DATE.PRM
This field will hold a history of the dates on which premium(s) were paid to this account. The dates will be stored in a descending order. The field will be updated automatically by the system.
Validation Rules:
CASH.POOL.GROUP
Stores the cash pool group id linked with this account
Validation rules
No input
CATEGORY
Indicates the Category code for the Account. The Category code is used to classify financial transactions on T24 according to the type of business operation or product type.
The first two digits of the Category code represent the highest level classification and the next three digits represent a sub-classification which provides a clear definition of the profit and loss or product type.
The use of these codes, together with personal Customer characteristics, e.g. Residence, Status, Industry and Sector codes etc., will enable the bank to produce balance sheets and returns reflecting a co-ordinated and structured view of its operation, by directing business transactions to their
appropriate place on the report.
Category codes in the range 01000 - 02999 have been predefined as 'Customer Current Accounts', only Accounts with Category codes in this range will be selected automatically by other modules within T24 (such as Securities) as default Accounts for receipt of funds etc. when no other Account
is specified.
Validation Rules:
4-5 numeric character Category code (Mandatory input)
It must be an existing code on the CATEGORY table. (ref: General Tables).
For Customer Accounts, it must be in the range 1000 to 9999.
For Internal Accounts, it must be in the range 10000 to 19999.
The Category Code of a NOSTRO account may only be changed to another NOSTRO category.
CHARGE.ACCOUNT
Identifies the Customer Account to which charges are to be capitalised (booked).
This field is only used when charges are to be capitalised to a Customer Account which is different from the ID Account number. The Account number to which charges are to be booked should be entered. The account need not be for the same customer but must be for the same currency. If
this field is left blank, the ID Account number is assumed.
Validation Rules:
2-14 numeric characters Customer Account number or 3-10 type MNE (uppercase alpha or numeric or '.') characters. Account Mnemonic. (Optional input for Customer Accounts, not allowed for Internal Accounts. No default value.) It must be an existing Customer Account number. Account
number must not be equal to the ID. This field cannot be input if the ID of this Account has been specified as the Liquidation Account for another Account.
CHARGE.CCY
No input field and set to the currency of the account.
CHARGE.MKT
No input field, set to the currency market of the CHARGE.ACCOUNT if input otherwise set to the currency market of the account.
CLOSED.ONLINE
Field introduced in G13.2
This field is updated by the system when the field CLOSE.ONLINE in the application ACCOUNT.CLOSURE is set to Y and committed.
Once this field is set to Y, then no more transactions are allowed in the account. An error message will appear if this account is used in any of the applications.
If the ACCOUNT.CLOSURE record is subsequently deleted, then this field will be restored back to NULL
Validation Rules:
System generated field - No Input
CLOSURE.DATE
This field indicates the date on which an account is closed.
The date here is the actually date that the account is closed and written to history. If the account is reopened using the H function this field is cleared.
Validation Rules:
Internal system field.
CLOSURE.NOTES
Holds the notes for closing the Account. This is a NOINPUT field which gets updated from the ACCOUNT.CLOSURE table.
Validation Rules:
CLOSURE.REASON
Holds the reason for closing the Account. This is a NOINPUT field which gets updated from the ACCOUNT.CLOSURE table.
Validation Rules:
CON.CHARGE.ACCR
Contains the key of the consolidation record (in the CONSOLIDATE.ASST.LIAB file) into which the details of the charge account, if any, are being consolidated.
Validation Rules:
Alphanumeric as specified in the consolidate conditions file (CONSOLIDATE.COND) (Internal field)
CON.INTEREST.ACCR
Contains the key of the consolidation record (in the CONSOLIDATE.ASST.LIAB file) into which the details of the interest account, if any, are being consolidated.
Validation Rules:
Alphanumeric as specified in the consolidate conditions file (CONSOLIDATE.COND) (Internal field)
CONDITION.GROUP
Indicates the group of Accounts to which this Account belongs for the purpose of specifying rules for the calculation of interest and charges. The group is determined automatically on the basis of Customer and Account details as specified in the Account General Condition table
(ACCT.GEN.CONDITION).
Conditions for the calculation and application of interest and charges are specified for groups of Accounts in the GROUP.CREDIT.INT, GROUP.DEBIT.INT and GROUP.CAP tables and can be overridden with special conditions for individual Accounts by specifying ACCOUNT.CREDIT.INT,
ACCOUNT.DEBIT.INT and ACCT.CAP records as required.
Account groups are determined automatically on the basis of Customer and Account details such as Account Category, Sector, Residence etc. as specified in the Account General Condition table (ACCT.GEN.CONDITION).
The criteria used and their order of priority are specified in the CONDITION.PRIORITY table in the record whose Id is 'ACCOUNT'.
If any of the Customer or Account details used to determine the Condition Group are changed, a new Group Condition code will be generated automatically. This may result in automatic adjustment of previously calculated interest.
For Account detail changes, the Condition Group is recalculated and updated when the record is Authorised. For Customer record changes, the Condition Group is actually updated during end of day processing, but the new Group is calculated and displayed whenever the Account record is
viewed as soon as the Customer record has been Authorised.
Validation Rules:
4 numeric characters. (No input. Automatically generated field.)
CONSOL.KEY
Contains the key of the Consolidation record (in the CONSOLIDATE.ASST.LIAB file) into which the details of this Account are being consolidated.
Validation Rules:
Alphanumeric, as specified in the Consolidate Conditions file (CONSOLIDATE.COND). (Internal field.)
CONSOLIDATE.ENT
If entries are to be consolidated the field CONSOLIDATE.ENT should contain the id to the AC.CONSOLIDATE.COND record that describes rules for consolidation. If it is set then statement 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
The combined key is structured as follows, the “!” character is used as a delimeter, for example a consolidated entry from the FT application may look like:
S!12345678!GBP!FT!210!20021126!!!1!!89
Validation Rules:
- A valid id to AC.CONSOLIDATE.COND table.
- For records defined as INTERNAL or NOSTRO Type ACCOUNTS a value of NO is also allowed. Once set this account will then be excluded from any consolidation processing.
CONTINGENT.BAL.CR
Credit balance held in contingent when operating in a value dated accounting system.
When operting in a value dated accounting system (ACCOUNT.PARAMETER) this field will show the total of all credits booked with a forward value date. However, this only includes credits booked through Funds Transfer, Teller & Data Capture and will not reflect deposits maturing etc. This field
is primarily used to recreate the contingent credit balance in the CRB.
Validation Rules:
Standard Amount Format. (Internal Field)
CONTINGENT.BAL.DR
Debit balance held in contingent when operating in a value dated accounting system.
When operting in a value dated accounting system (ACCOUNT.PARAMETER) this field will show the total of all debits booked with a forward value date. See CONTINGENT.BAL.CR for further details.
Validation Rules:
Standard Amount Format. (Internal Field)
CONTINGENT.INT
This field decides whether the account is contingent or not. Whether the field should be populated is dependent on the category of the account. If the category of the account is within the range specified in ACCOUNT.PARAMETER then input is mandatory, otherwise input is not allowed.
The value of the field will be initially defaulted from ACCT.GROUP.CONDITION. This value can be manually overriden. Possible inputs are B,C,O,I and "" and as follows
B - Indicates non-contingent interest
C - Indicates contingent interest, which should not appear on the balance sheet.
O - Indicates non-contingent interest, reported as an off balance sheet item
I Indicates an Internal Contingent account, which is used to counterbalance contingent accounts. Again, this should not appear on the balance sheet.
"" - Indicates account is not contingent
Validation Rules:
1. If the account is contingent this field should be populated and otherwise not.
2. If the account is contingent the category code of the account should satisfy the condition defined in Fields CONT.DESC, CONT.CAT.STR, CONT.CAT.END, CONT.DR.TXN and CONT.CR.TXN in ACCOUNT.PARAMETER
3. ACCT.GEN.CONDITION for a particular group can have either contingent or non-contingent categories but not both.
4. The fields INTEREST.LIQU.ACCT and CHARGE.ACCOUNT in ACCOUNT, if populated, are always non-contingent and should be populated, if the account is contingent. This should only be the case for non-contingent interest (option B).
5. The fields INTEREST.COMP.ACCT, AUTO.PAY.ACCT, ICA.MAIN.ACCOUNT in ACCOUNT are optional and if populated, should be of the same contingent type as the account.
CR.ADJ.AMOUNT
The credit interest adjustment amount which has been accrued, (booked to Profit and Loss), but has not yet been capitalised (booked to the Customer's Account).
CR2.ADJ.AMOUNT
The 2nd credit interest adjustment amount which has been accrued, (booked to Profit and Loss), but has not yet been capitalised (booked to the Customer's Account).
CREDIT.CHECK
Identifies on which balance, overdraft and limit checking should be made. It can be set at ACCOUNT level or at the ACCT.GROUP.CONDITION or ACCOUNT.PARAMETER level.
The flag will be selected in the following order:
1. ACCOUNT
2. ACCT.GROUP.CONDITION, if not set at ACCOUNT level
3. ACCOUNT.PARAMETER, if not set at ACCT.GROUP.CONDITION level
Validation Rules:
AVAILABLE: Credit checking is made using AVAILABLE.BAL
WORKING: Credit checking is made using WORKING.BALANCE
FORWARD: Credit checking is made using WORKING.BALANCE plus today's forward movements.
AVAILWORK: Credit checking is made using AVAILABLE.BAL and WORKING.BALANCE.
AVAILFWD: Credit checking is made using AVAILABLE.BAL and WORKING.BALANCE plus today's forward movements.
BLANK: The default checking is using WORKING.BALANCE
COMPONENT: Credit checking is made using the balance components configured based on AC.CREDIT.CHECK. This option is applicable only for AR Accounts
CREDIT.CHK.CONDITION
Field to decide if credit check processing to be performed for the account based on the conditions defined in the field CREDIT.CHK.TXN.TYPE
Validation Rules:
Optional Field
Field can be input only through Arrangement
Yes/NULL - Credit Check Processing will be done
No - Credit Check Processing will not be done
CREDIT.CHK.TXN.TYPE
Field to define credit checking conditions in conjunction with the field CREDIT.CHK.CONDITION
Validation Rules:
Optional Field
EXTERNAL - Credit Checking Condition defined in the field CREDIT.CHK.CONDITION will be considered only for transaction codes marked as External
INTERNAL - Credit Checking Condition defined in the field CREDIT.CHK.CONDITION will be considered only for transaction codes marked as Internal
NULL - Credit Checking Condition defined in the field CREDIT.CHK.CONDITION will be considered only for transaction codes marked as Internal as well External
CREDIT.MOVEMENT
Identifies the total credit movements to the account valued on the date specified by field VALUE.DATE above.
This field is provided to show the daily credit movements to accounts on the date specified in field VALUE.DATE above. This together with the DEBIT.MOVEMENT field below will be used to make up the VALUE.DATED.BAL, and is used for overdraft and limit checking.
For all Accounts, this field is updated by all forward entries when they have been fully authorised, and fall within the cash flow period as specified on field CASH.FLOW.DAYS from the ACCOUNT.PARAMETER file.
Validation Rules:
Standard Amount Format. (Internal Field) This field forms a multi value set with fields VALUE.DATE and VALUE.DATED.BAL.
CURRENCY
Identifies the Currency of the Account.
All entries passed to the Account must be in this Currency.
Once the Account record has been authorised, the Currency cannot be amended.
Validation Rules:
3 type SSS (uppercase alpha) character or 1-3 numeric character Currency code. Cannot be changed after record has been authorised. (Mandatory Input)
It must be an existing code on the CURRENCY Table.
CURRENCY.MARKET
Identifies the Currency Market for exchange rate information for this Account, in countries where different rates are quoted for the same Currency.
The use of this field is only applicable in countries where the exchange market defines different rates for the same Currency, according to rules determined by the local authorities or central bank.
A typical example would be Belgium, where foreign currencies are quoted on the Regular Market and also on the Free Market. Different sets of exchange rates exist for these two markets.
The Currency Market flag may also be used to denote notional markets, i.e. where the User would like to define different sets of exchange rates according to the type of product handled.
Validation Rules:
1 numeric character Currency Market code. (Optional Input. Default is 1.) Cannot be changed.
It must be an existing code on the CURRENCY.MARKET table.
Details for the Currency Market specified must be included in the CURRENCY record.
CUSTOMER
Identifies the Customer to whom the Account belongs.
This field maintains a link between the Customer and their Accounts. Internal Accounts are recognised by ID's which contain a Currency Code in the first 3 characters. These do not belong to Customers.
Validation Rules:
1-10 numeric character Customer Code or 3-10 type MNE (uppercase alpha or numeric or '.') character Customer Mnemonic. (Mandatory input for Customer Accounts not allowed for Internal Accounts). Can only be changed for Nostro accounts. A change is only allowed if the account is not
specified in the EXT.ACCT.NO field of the AGENCY record for the old Customer number. Input here will be checked against the account number if an entry has been made in the customer code position on account parameter. This check is for account numbers that contain the customer code,
the position within account number being specified by account parameter.
Customer number can be changed only if the Account category 1000 to 9999 is specified in the field range ACCT.CATEG.STR and ACCT.CATEG.END of ACCOUNT.PARAMETER. This will allow change only if the account has joint holders and also allows the change only to a joint holder customer.
Cannot change the customer if there are LIMITS attached to the account, if it is single customer account without joint holders and if the account has been input as an AUTO.PAY.ACCOUNT or SUB ACCOUNT in another account with same main customer and currency.
Will allow change to Nostro accounts even if the account category is specified in ACCOUNT.PARAMETER.
CUSTOMER.CODE
CUSTOMER.MNEMONIC
DATE.LAST.CR.AUTO
Contains the date when the last automatically generated credit entry was passed to this Account. (An indicator in the TRANSACTION table indicates whether entries for each Transaction code are generated by the Customer or by the Bank or Automatically from a previous Customer instruction.)
Automatic are items like Standing Orders, i.e. where the Customer has given instructions in the post and the bank is acting on them.
Validation Rules:
DATE.LAST.CR.BANK
Contains the date when the last bank generated credit entry was passed to this Account. (An indicator in the TRANSACTION table indicates whether entries for each Transaction code are generated by the Customer or by the Bank or Automatically from a previous Customer instruction.)
Validation Rules:
DATE.LAST.CR.CUST
Contains the date when the last Customer generated credit entry was passed to this Account. (An indicator in the TRANSACTION table indicates whether entries for each Transaction code are generated by the Customer or by the Bank or Automatically from a previous Customer instruction.)
Validation Rules:
DATE.LAST.DR.AUTO
Contains the date of the last automatically generated debit entry passed to this Account. (An indicator in the TRANSACTION table indicates whether entries for each Transaction code are generated by the Customer or by the Bank or Automatically from a previous Customer instruction.)
Automatic are items like Standing Orders, i.e. where the Customer has given instructions in the post and the bank is acting on them.
Validation Rules:
DATE.LAST.DR.BANK
Contains the date of the last bank generated debit entry passed to this Account. (An indicator in the TRANSACTION table indicates whether entries for each Transaction code are generated by the Customer or by the Bank or Automatically from a previous Customer instruction.)
Validation Rules:
DATE.LAST.DR.CUST
Contains the date when the last Customer generated debit entry was passed to this Account. (An indicator in the TRANSACTION table indicates whether entries for each Transaction code are generated by the Customer or by the Bank or Automatically from a previous Customer instruction.)
Validation Rules:
DATE.LAST.UPDATE
The system date of the last time the account record was moved
Validation Rules:
DEBIT.MOVEMENT
Identifies the total debit movements to the account valued on the date specified by field VALUE.DATE above.
This field is provided to show the daily debit movements to accounts on the date specified in field VALUE.DATE above. This, together with the CREDIT.MOVEMENT field above, will be used to make up the VALUE.DATED.BAL, and is used for overdraft and limit checking.
For Nostro and Internal Accounts, it is updated by all debit entries when they have been fully Authorised.
For other Customer Accounts it is updated by forward debit entries when they are Validated.
Validation Rules:
Standard Amount Format. (Internal field) This field forms a multi value set with fields VALUE.DATE and VALUE.DATED.BAL.
DISPO.EXEMPT
Dispo Exempt (DISPO.EXEMPT)
This field specifies whether a particular Transaction Type will be subject to Dispo processing.
Validation Rules:
DISPO.OFFICER
The DISPO.OFFICER who is responsible overall for the ACCOUNT.
Where there is no DISPO.OFFICER specified at the ACCOUNT level, the DISPO.OFFICER specified for the CUSTOMER will be used.
Validation Rules:
Up to 4 numeric digits
Valid Dispo Officer as set up in the DISPO.OFFICER file.
DR.ADJ.AMOUNT
The debit interest adjustment amount which has been accrued, (booked to Profit and Loss), but has not yet been capitalised (booked to the Customer's Account).
DR2.ADJ.AMOUNT
The 2nd debit interest adjustment amount which has been accrued, (booked to Profit and Loss), but has not yet been capitalised (booked to the Customer's Account).
EMERGENCY.BLOCK
YES or NO
EXTERN type
Reserved for future use
EMERGENCY.REASON
Reason for emergency block.
EXTERN type
END.DATE
ENTRY.HOLD
Will contain the keys to any ENTRY.HOLD records.
Validation Rules:
EXTERN field.
EP.BALANCE
This field will hold the balance of the expected payments due to this account, if the account is defined in the process AC.EXPECTED.RECS
Validation Rules:
System generated and maintained
ER.BALANCE
Where an account is defined to be process AC.EXPECTED.RECS this field will show the net amount of the records Expected and Received. If a receipt is processed without the expected record it can be possible for a negative amount to show.
Validation Rules:
ER.VALUE.DATE
Where an account is defined to be process AC.EXPECTED.RECS this field will show the value date of the records Expected and Received.
Validation Rules:
EVENT
Indicates the items/events that are to be triggered.
This field gets populated while creating a record in EB.ALERT.REQUEST with CONTRACT.REF = ACCOUNT.NO.
Validation Rules:
Must be a valid ID in TEC.ITEMS.
EXPOSURE.DATES
The future exposure dates for an account.
Validation Rules:
NOINPUT field
EXTERNAL.POSTING
This field indicates if the account allows entries posted from outside the network of Summary accounts. This field should only be set for Summary accounts and Funds Diversion accounts inside a Summary account network
Validation Rules:
Can be set to 'YES' or 'NO'
FA.STATUS
Is the Account synced
SYNC,ERROR and null.
EXTERN type
FIELD
The field to be monitored for which the alert is subscribed.
Associated multi value field of Event.
FIRST.AF.DATE
This field will hold the first available date of the ladder.
Validation Rules:
FORWARD.MVMTS
Identifies the authorised forward movements to the account with an exposure date specified by field AVAILABLE.DATE above.
This field is provided to show the authorised daily forward movements to accounts on the date specified in field AVAILABLE.DATE above.
It is updated by all credit and debit entries when they have been fully Authorised.
Validation Rules:
FROM.DATE
This field and the related LOCKED.AMOUNT form a multi-value set indicating an amount of funds that have been blocked (reserved) for specific purposes and so should not be paid out from the account.
The field is 'no input' and is populated through input of an event in the AC.LOCKED.EVENTS application and indicates the date from which the related LOCKED.AMOUNT is to be held.
Input of multiple AC.LOCKED.EVENTS records for an account will result in a 'ladder'; of these related fields being created, with a final one for zero amount from the date that no funds are blocked.
Dependant on the type of credit checking employed on the account, the system will either check the highest LOCKED.AMOUNT against the WORKING.BALANCE or check each LOCKED.AMOUNT against each AVAILABLE.BALANCE within the cash-flow window. An override will be generated
whenever the applicable balance falls below the LOCKED.AMOUNT
Validation Rules:
No Input allowed
Standard T24 date field
FWD.ENTRY.HOLD
Will contain the keys to any FWD.ENTRY.HOLD records.
Validation Rules:
EXTERN field.
HVT.FLAG
The field HVT.FLAG in the account record controls whether an account is high volume or not.
Validation Rules:
No or Null indicates that it is not a high volume account.
If this field is set to Yes it indicates that this is an account, which has a high volume of transactions every day. High volume account processing is currently not enabled for AA accounts.
IC.CHARGE.ID
If this account is directly linked to an IC.CHARGE record, i.e. A_account@id then the IC.CHARGE key will be stored in this field.
This field will be extrenally updated from the IC.CHARGE application when the relevant IC.CHARGE record is created or reversed. If this account is linked to an IC.CHARGE record via the account condition group - currency, or condition group then this field will not be updated.
IC.LST.PROD.CAP
This multi valued field asscociated with IC.PRODUCT will contain the last capitalisation date for that IC.CHARGE.PRODUCT. When an IC.CHARGE.PRODUCT is capitalised for this account then these fields will be updated in the same manner as the interest capitalisation fields. If an
IC.CHARGE.PRODUCT is capitalised for the first time then the latest of the last normal charge capitalisation date, or the effective date on the relevant IC.CHARGE record will be used as the start of the charge period.
IC.NEXT.CAP.DATE
This No Input field will contain the next capitalisation date for any IC.CHARGE.PRODUCT associated with this account. It will be externaly updated whenever an IC.CHARGE record directly linked to this account is modified or the actual IC.CHARGE.PRODUCT is capitalised.
IC.PRODUCT
This multi valued field associated with IC.LST.PROD.CAP will contain the IC.PRODUCTS relevant to this account. This field will be updated whenever an IC.PRODUCT relevant to this account is capitalised.
ICA.ADD.REMOVE
ICA.ADD.REMOVE
Defines whether a link to an ICA main account is to be added or removed.
The default is to add a link.
Validation Rules:
Can only be input if ICA.MAIN.ACCOUNT is input.
Optional Input, default is ADD.
Input can either be ADD or REMOVE.
ICA.BACK.VALUE
ICA.BACK.VALUE
Contains the furthest back valued date for which an ICA account requires adjustment.
This field is updated by the system during the end of day processing whenever a back value capitalisation correction takes place on an account. It is cleared during the same end of day.
Validation Rules:
No Input
Standard T24 date field
ICA.DISTRIB.RATIO
ICA.DISTRIB.RATIO
If the main account to which this sub account is linked has an interest distribution type of RATIO then the percentage of the difference between group and normal interest allocated to this account is defined here.
If the main account to which this account is linked has an interest distribution type of INTEREST then no input is required here.
The distribution type of RATIO indicates that a straight percentage of the group interest is allocated to an individual account with the exception of the main account in the group, which receives the remainder of the group interest.
For the ratio method the default is zero interest indicating that 100% of the group interest will go to the main account in the group.
The total percentage of group difference interest allocated to the sub accounts in a group cannot exceed 100.
If a link is changed during a capitalisation period then the percentage of interest allocated to this account will be backed out. I.e. the ICA.DISTRIB.RATIO on this account will be set to zero, and the ICA.MAIN.RATIO value of the main account will be decreased by the percentage formerly
allocated to this account.
In other words the percentage allocated to this account is only relevant at the end of the capitalisation period. If a sub account is linked to a main account one day before the capitalisation date and is set to receive 50% of the group interest difference then it will receive 50% of the interest
difference for the whole capitalisation period.
Validation Rules:
Input only allowed if the main account in this group has an ICA.DSITRIB.TYPE of RATIO.
The value in this field plus the value of the ICA.MAIN.RATIO field of the main account to which this sub account is linked cannot exceed 100.
ICA.DISTRIB.TYPE
ICA.DISTRIB.TYPE
If this account is defined as an ICA main account (ICA.MAIN.ACCT.IND = "YES") then this field is used to indicate the type of interest distribution used.
ICA interest is calculated when the main account is capitalised and is defined as follows.
ICA Group Difference = ICA Group Interest - ICA Normal Interest
ICA Group Interest is calculated by combining the balances of all accounts for the times that they were members of an ICA group. An ACCT.ACTIVITY record for the group with the key of MAIN.ACCOUNT*-YYYYMM (where YYYY is the year and MM is the month) is created. And the standard
interest processing takes place based on the interest conditions of the main account. STMT.ACCT.XX records are written out for the group with the same key as for ACCT.ACTIVITY with a key of MAIN.ACCOUNT*SUB.ACCOUNT-YYYYMMDD.
Normal Interest is calculated as the total interest of all accounts in the group for the time that the accounts were group members during the calculation period.
If an account was only a partial member of the group during the calculation period then the partial normal interest is calculated. An ACCT.ACTIVITY record containing the balances of the account for the time it was a group member with a key of MAIN.ACCOUNT*SUB.ACCOUNT-YYYMM. Standard
T24 interest processing takes place and STMT.ACCT.XX records are written for the sub account with the key of MAIN.ACCOUNT*SUB.ACCOUNT-YYYYMMDD.
The ICA Group Difference is distributed to the accounts in the group by one of two methods.
RATIO Method, the percentage of group interest defined in ICA.DISTRIB.RATIO for the sub account is allocated to the sub account.
INTEREST Method, The amount of interest earned by the sub account is used to determine the interest allocated to the sub account as follows
ICA Group Difference * ( Normal Interest / Interest earned by sub account)
In both cases the remainder of the ICA Group Difference is allocated to the main account.
NB. ICA interest only is distributed, charges and taxes are not applicable to this type of interest distribution.
Validation Rules:
Input is mandatory if this account is defined, as an ICA main account otherwise input is not allowed.
Can be either RATIO or INTEREST.
ICA.MAIN.ACCOUNT
ICA.MAIN.ACCOUNT
Defines the main account in an Interest Compensation Account (ICA) Hierarchy to which this account is linked.
An ICA hierarchy consists of linked groups of accounts, each group consists of a main account together with an unlimited number of sub accounts.
A sub account in one group can be a main account in a lower level group.
There can be an unlimited number of group levels in an ICA hierarchy.
The main account in the top-level group is called the top account.
To define an ICA hierarchy the top account in the hierarchy must be defined in the ICA.HIERARCHY application. The definitions of the hierarchy must begin with the top-level account of the top-level group, and proceed to successively lower level groups. The top account in the hierarchy is
linked to itself.
This field contains the account to which this account is currently linked.
To define a link input is made using the ICA.NEW.MAIN.ACC field together with the ICA.START.DATE and ICA.ADD.REMOVE.FIELDS.
Validation Rules:
No Input Field
Standard T24 account number.
The field
ICA.MAIN.ACCOUNT in
i.e. if the field
CONTINGENT.INT
ICA.MAIN.ACCOUNT
if the field
CONTINGENT.INT
ICA.MAIN.ACCOUNT
ICA.MAIN.ACCT
ICA.MAIN.ACCT
This multi value field is updated by the system and contains a list of main accounts to which this account has been linked in chronological order starting with the most recent (i.e. current).
It is associated with the ICA.MAIN.DATE field, which stores the date that the link became active.
If an account has been removed from an ICA hierarchy then the account number will be prefixed with "REMOVED " and ICA.MAIN.DATE will contain the date that the link was terminated.
Validation Rules:
No input field
Updated by the system, can contain an account number or an account number prefixed by "REMOVED "
ICA.MAIN.ACCT.IND
ICA.MAIN.ACCT.IND
Input of YES indicates whether this account is a main ICA (Interest Compensation Account hierarchy) account, i.e. the lead account of an ICA group.
A main account in one group can be a sub account in another higher level group.
The main account in an ICA group is used to determine the type of interest distribution used.
It will always receive the remainder of any group difference after any group interest has been allocated to sub accounts.
If a main account of one group is also a sub account of a higher level ICA group then it can receive ICA interest from both groups.
Validation Rules:
Optional Input
Can only be input if ICA.MAIN.ACCOUNT is populated.
Input can either be YES NO or Null (left blank)
ICA.MAIN.DATE
ICA.MAIN.DATE
This multi value field is updated by the system and contains a list of start dates for links to the main accounts to which this account has been linked in chronological order starting with the most recent (i.e. current).
It is associated with the ICA.MAIN.ACCT field.
If an account has been removed from an ICA hierarchy then the account number will be prefixed with "REMOVED " and ICA.MAIN.DATE will contain the date that the link was terminated.
Validation Rules:
No input field system updated.
Standard T24 date field.
ICA.MAIN.RATIO
ICA.MAIN.RATIO
This field contains the total percentage of group interest (for which this account is the main account) allocated to the sub accounts of the group.
This field is updated by the system if this account is defined as a main account (ICA.MAIN.ACCT.IND = "YES") and the interest distribution type is RATIO (ICA.DISTRIB.TYPE = "RATIO").
This field is updated whenever a sub account has the ICA.DISTRIB.RATIO field updated.
The main account of the group will receive the remainder i.e. if 75% of the group interest allocated to sub accounts then 25% will be allocated to the main account.
Validation Rules:
No Input field
Numeric field, should not contain a value > 100.
ICA.NEW.MAIN.ACC
ICA.NEW.MAIN.ACC
Defines the main account in an Interest Compensation Account (ICA) Hierarchy to which this account is to be linked.
An ICA hierarchy consists of linked groups of accounts, each group consists of a main account together with an unlimited number of sub accounts.
A sub account in one group can be a main account in a lower level group.
There can be an unlimited number of group levels in an ICA hierarchy.
The main account in the top-level group is called the top account.
To define an ICA hierarchy the top account in the hierarchy must be defined in the ICA.HIERARCHY application. The definitions of the hierarchy must begin with the top-level account of the top-level group, and proceed to successively lower level groups. The top account in the hierarchy is
linked to itself.
It is possible to back value the link to any date within the current capitalisation period of the main account, to do this use the ICA.START.DATE field, the default date is TODAY. If a link is back valued then any links made between the back value date and today will be removed.
To remove a link the ICA.ADD.REMOVE field is used, the default is to add a link. An account cannot be removed from an ICA hierarchy if it has accounts linked to it.
To remove a main account from a hierarchy the sub accounts linked to it must be either linked to other main accounts or removed from the hierarchy completely.
An account can be linked to any other account which is defined as an ICA main account assuming that the validation conditions are met.
It is also possible to link an account to a main account in another hierarchy.
If this account is also a main account then any accounts linked to this account will also be linked to the new main account through this account. In this way it is possible to move a complete sub structure of the hierarchy by changing the link of the highest level account of that sub structure.
Each main account has a corresponding ICA.GROUP.DETAIL record, which contains historical data of all linked relationships, both for accounts linked to and accounts linked from the main account. ICA.GROUP.DETAIL also contains details of ICA group interest distribution. ICA.GROUP.HISTORY
contains interest distribution information for each time that the account was capitalised. ICA.GROUP.DETAIL will be updated on authorisation of the account record.
Validation Rules:
The account to link to must meet the following criteria.
The currencies of the two accounts must be the same or be members of the same fixed currency group, e.g. EUR "IN" currencies.
The main account to which this account is to be linked must be defined as an ICA main account (ICA.MAIN.ACCT.IND = "YES")
If the account to link to is this account i.e. the top-level account of an ICA.HIERARCHY then the account must be defined in an ICA.HIERARCHY record
The main account to link to must not be set for automatic or pending closure
An Override will be generated if the capitalisation frequency of the main account to link to does not meet the following criteria.
The interest capitalisation frequencies of the two accounts must be the same or
If the capitalisation is monthly both accounts must have the same capitalisation day, the main account to link to can have a capitalisation frequency greater than this account. E.g. it is possible to link this account which, capitalises monthly on the 15
N.B using OVERRIDE.CLASS the overrides generated due to incompatible capitalisation frequencies can be treated as validation errors.
ICA.POST.INTEREST
ICA.POST.INTEREST
Indicates the type of interest posting for an ICA account. Interest posting can be set to
YES - ICA interest is calculated and any interest due to the account is posted to it
INFO - ICA interest is calculated and STMT.ACCT.XX records are updated but interest is not to posted to the account
OFF - ICA interest is not calculated, STMT.ACCT.XX records are not created and no interest posting takes place.
NB.
If interest posting is set to OFF for a main account then this has the effect of turning off ICA interest processing for the whole group.
If interest posting is set to INFO for a main account the interest will be allocated to sub accounts but no interest will be posted to the main account.
Validation Rules:
Optional input default is YES.
Can only be input if ICA.MAIN.ACCOUNT is populated.
If the INFO option is chosen then the field INT.NO.BOOKING must be set to "Y" .
ICA.START.DATE
ICA.START.DATE
Defines the start date of the link to the ICA main account defined in ICA.NEW.MAIN.ACC.
The default date of the link is today.
Account links can be back valued as far as the first day of the current interest capitalisation period, whichever is closest to today of credit, credit 2, debit and debit 2.
Validation Rules:
Standard T24 date field.
Can only be input if ICA.NEW.MAIN.ACC is also input.
Any back value date cannot be earlier than the first day of the current capitalisation period of this account.
INACTIV.MARKER
This marker is set whenever the dates of the last credit and debit entries generated by the Customer (Last Credit Customer and Last Debit Customer fields) are more than x months ago, where x is the number of months specified in the Company record. When this marker is set, no entries will
be accepted without an override.
This marker is set during the end of day processing. It can only be reset by running a special Account Inactive Reset program.
Validation Rules:
(Internal field.)
INT.LIQ.CCY
No Input field
Set to the currency of the associated liquidation account.
INT.LIQU.ACCT
Specifies the interest liquidation account
Multi valued field associated with INT.LIQU.ACCT and INT.LIQ.CCY
Optional input and must be input if the associated interest liquidation type is input.
The liquidation account must not equal this account @id.
The currency of the liquidation account can be different to the currency of this account.
Default currency exchange will be at the mid rate of currency market 1.
All accruals will take place in the original currency. The currency exchange will only take place on capitalisation and only for the entries to the liquidation account..
It is possible to set up threshold amounts and currency markets for mid rate exchange on the relevant ACCT.GROUP.CONDTION record. If the interest amount exceeds the largest threshold amount then an FT will be created on hold to allow the user to control the rate used and the time that
the posting takes place.
INT.LIQU.TYPE
Specifies the type of interest to be liquidated.
Multi valued field associated with INT.LIQU.ACCT and INT.LIQ.CCY
Optional input
If input must be one of the following values wit no duplicates.
DR - both debit interest types
DR1 - debit interest 1 liquidation
DR2 - debit interest 2 liquidation
CR - both credit interest types
CR1 credit interest 1 liquidation
CR2 credit interest 22 liquidation
INT.NO.BOOKING
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 and not booked to Profit and Loss, or is for information only (e.g. for Nostro Accounts).
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 e.g. for bad and doubtful
debts.
If this field 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, e.g. for Nostro Accounts.
Validation Rules:
'SUSPENSE' or 'Y'. (Optional input. No input means interest and charges will be accrued and booked as normal.)
It is not possible to remove 'SUSPENSE' from this field if the record contains any suspensed interest and charges amounts in fields ACCR.CHG.SUSP, ACCR.CR.SUSP, ACCR.CR2.SUSP, ACCR.DR.SUSP or ACCR.DR2.SUSP. See ACCT.SUSP.SETTLE for further details.
It is not possible to enter 'SUSPENSE' in this field if the ACCOUNT is flagged for closure (i.e. if the POSTING.RESTRICT field contains a value in the range 90-99).
INTEREST.CCY
No Input field and defaulted to the currency of the account.
INTEREST.COMP.ACCT
Identifies the main Account for the purpose of consolidating the balances of various accounts in the same currency or in the same fixed currency group, before interest is calculated and applied.
This field is only used when the balances of several accounts are to be consolidated before interest is calculated and applied. All the Accounts involved must be in the same Currency or the same fixed currency group The main Account number determining the Group or Account interest
conditions applicable should be entered.
Validation Rules:
2-14 numeric characters Customer Account number or 3-10 type MNE (uppercase alpha or numeric or '.') character Account Mnemonic. (Optional input for Customer Accounts, not allowed for Internal Accounts. No default value.) It must be an existing Account number. Account must be in the
same Currency or the same fixed currency group as this record. Account number must not be equal to the ID of this record. The Account referred to in this field must not itself be a sub-account of another group of Accounts to be combined for interest purposes, i.e. there must be no input in
the INTEREST.COMP.ACCT field in the Account record for the Main Account. This field cannot be input if the ID of this Account has been specified as the Compensation Account for another Account.
INTEREST.LIQU.ACCT
Identifies the Account to which interest is to be capitalised (booked).
This field is only used when interest is to be capitalised to an Account which is different from the ID Account number. The Account number to which interest is to be booked should be entered. The account need not be for the same customer but must be for the same currency. If this field is
left blank, the ID Account number is assumed.
Validation Rules:
2-16 characters Account number or 3-10 type MNE (uppercase alpha or numeric or '.') character Account Mnemonic. No default value.
It must be an existing Account number. Account number must not be equal to the ID. This field cannot be input if the ID of this Account has been specified as the Liquidation Account for another Account.
INTEREST.MKT
No input field and set to the currency market of the interest liquidation account.
JOINT.HOLDER
This field must contain a customer number being made a joint holder of this account.
Validation Rules:
If entered this field must contain a valid customer number.
Optional field.
JOINT.NOTES
This field can contain any documentary information pertaining to the JOINT.HOLDER.
Validation Rules:
This field cannot be entered if the JOINT.HOLDER field has not been entered.
If the JOINT.HOLDER field has been populated then this field is optional.
LAST.COM.CHG.DATE
This field will hold the date on which an account has moved to a different company.
Validation Rules:
EXTERN field - no input
LEDG.RECO.WITH
Identifies the Internal Account to which the ID account number is reconciled.
This field is used to reconcile Internal accounts within Nostro Reconciliation. The account entered may not be a Nostro account and must be of the same currency as the ID account number.
Validation Rules:
2-16 numeric characters Account Number or 3-10 type MNE (uppercase alpha or numeric or '.') character account mnemonic (Not allowed for Nostro Accounts, no default value)
Must be an existing Account Number.
Account number must not be equal to ID account number.
Account must be the same currency as ID Account number.
LIMIT.KEY
LIMIT.PROC.TYPE
LIMIT.REF
If the Customer has a Credit Limit covering this Account, this 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 this 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 (see below). 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.
The key to the corresponding Limit record is built up as follows: cccccc.nnnnnnn.ss
Where 'cccccc' is the Liability number for the Customer in Field CUSTOMER of this record and 'nnnnnnn.ss' is the Limit Reference specified in this field.
Validation Rules:
3-9 numeric characters consisting of a 3-7 digit Limit Reference Code and optionally, a 2 digit sequence number separated by '.' (or) upto 15 characters consisting of 1-12 Limit Reference Code and Optionally 2 digit serial number separated by '.' (Or) 'NOSTRO' to denote a Nostro Account
(generated automatically by the system). (Optional input. No default.)
The Limit Reference Code (nnnnnnn) must be an existing code on the LIMIT.REF table.
Limit Reference code must be a suitable one for Account records, as defined in the Limit Parameter table.
There must be a Limit record corresponding to the key built up as described above.
Error message is generated if single limit is set to "Y" and one more accounts is attached to same limit (If single limit field is set to "Y" then the limit can be utilised by one account. If multiple accounts are to utilise a single limit then, single limit field to be defined as "N" for all such accounts.
LINK.TO.LIMIT
Defines whether account particular limits are to be linked to the LIMITS file.
If this field is set to YES, the debit interest conditions for the account will be set according to the current value of the allocated limit amount (ONLINE.LIMIT) for the lowest defined record in the limit structure. The agreed overdraft limit can be specified either as an ACCOUNT.DEBIT.LIMIT
record in conjunction with the GROUP.DEBIT.INT record, or as the first band of the ACCOUNT.DEBIT.INT record.
Where an ACCOUNT.DEBIT.INT record is defined for the account, the first band of the DEBIT.INT.RATE rate field will be set to the available amount in the end of day processing, effective the date the limit value changes.
Where no ACCOUNT.DEBIT.INT record is defined for the account, the LIMIT amount will be set to the limit amount available, effective the date the limit amount changes.
Note that them link will only be maintained under the following circumstances:
- The limit is not defined at the Global level. - The limit currency is the same as the account currency. - The limit is utilised only by one account.
When this field is set to YES initially, the system wil create an ACCOUNT.DEBIT.LIMIT record for the system date based on the existing limit value, if no ACCOUNT.DEBIT.INT record is defined for the account.
Validation Rules:
YES or NO (Optional Input)
LIQUIDATION.MODE
This field identifies the manner in which overdue payments are handled.The default for all contracts is
AUTOMATIC.
There are three options available:
AUTOMATIC,SEMI-AUTOMATIC,MANUAL
AUTOMATIC will liquidate across the settlement accounts on the contract.
MANUAL will create a PD contract instead.
SEMI-AUTOMATIC will raise a PD contract if insufficient funds exist on the settlement account. For further details, see the helptext in PD.PARAMETER where these settings are controlled from.
Validation Rules:
If the PD parameter is not set for the company, the only value allowed is PD.
LOCK.INC.THIS.MVMT
To define which movement that has not updated Available funds should be included in the Locked Amount checking. Work at the same level with the field AVAILABLE.BAL.UPD. Values allowed depend on the Values defined in AVAILABLE.BAL.UPD.
Default is 'NONE' meaning any unauthorized movement that has not updated Available Balance will be ignored for locked amount checking.
Validation Rules:
'DEBITS' OR 'CREDITS' OR 'BOTH' OR 'NONE' OR Blank.
LOCKED.AMOUNT
This field and the related FROM.DATE form a multi-value set indicating an amount of funds that have been blocked (reserved) for specific purposes and so should not be paid out from the account.
The field is ‘no input’ and is populated through input of an event in the AC.LOCKED.EVENTS application and indicates the amount reserved for the period commencing on the related FROM.DATE through to the calendar day preceding the FROM.DATE of the following multi-value
set.
Input of multiple AC.LOCKED.EVENTS records for an account will result in a ‘ladder’ of these related fields being created, with a final one for zero amount from the date that no funds are blocked.
Dependant on the type of credit checking employed on the account, the system will either check the highest LOCKED.AMOUNT against the WORKING.BALANCE or check each LOCKED.AMOUNT against each AVAILABLE.BALANCE within the cash-flow window. An override will be generated
whenever the applicable balance falls below the LOCKED.AMOUNT
Validation Rules:
No Input Allowed
Numeric Amount field
LOCKED.WITH.LIMIT
When account is linked to a limit and has locked funds, the setup in this field identifies the following:
i. whether credit checking on Locked amounts will include limit
ii. whether credit checking on Limit will include the Locked amounts. It will be selected in the following order:
1. ACCOUNT
2. ACCT.GROUP.CONDITION (if ACCOUNT is blank)
3. ACCOUNT.PARAMETER (if ACCT.GROUP.CONDITION is blank)
For example if nothing is set at ACCOUNT level then the ACCT.GROUP.CONDITION is checked and if still nothing is set at this level, the ACCOUNT.PARAMETER is checked.
Validation Rules:
YES: Locked amount checking to use Limit
NO: Locked amount checking not to use Limit
LOCKED.ONLY: For locked amount based transactions, limit will be included
Blank: The default setting is not to use Limit
LONG.POS.SIGN
MANDATE.APPL
Holds the application name for which mandates need to be checked. Application that are eligible for mandate check are FUNDS.TRANSFER, BULK.STO,STANDING.ORDER,DD.DDI and FT.BULK.MASTER.
If this field is left blank, Mandate will be applied for all the eligible application.
Validation Rules:
It must have a valid record on EB.MANDATE.PARAMETER table.
MANDATE.RECORD
Specifies Mandate that need to be triggered. This will contain information about minimum signatories required for authorization of transaction.
Validation Rules:
It should have valid record in EB.MANDATE.
MANDATE.REG
Indicates the rule need to be triggered for Mandates.
if null then the mandate checking is always triggered. Field is linked to EB.RULE.GATEWAY table.
Validation Rules:
It is not a mandatory field.
MASTER.ACCOUNT
The MASTER.ACCOUNT defines the number of the master account for that sub account. Can be entered manually or updated on automatic account creation.
Manual update should also update the concat file AC.SUB.ACCOUNT keyed on the MASTER.ACCOUNT
Validation must ensure that the sub-account and master account have the same category, customer and currency as a minimum.
If this field is set then MAX.SUB.ACCOUNT cannot be set or vice versa.
Validation Rules:
Must be a valid ACCOUNT id
Is not allowed if MAX.SUB.ACCOUNT is set
MAX.SUB.ACCOUNT
The MAX.SUB.ACCOUNT field defines the maximum number that a Master account may hold.
It should be set to allow the automatic creation of sub-accounts and the automatic distribution of transactions over sub-accounts.
To allow sub-account processing, there should also be a record in AC.AUTO.ACCOUNT for the account category that Master account belongs to.
It cannot be defined if account is already a sub-account, that is if MASTER.ACCOUNT contains a value
Validation Rules:
Valid number between 1 and 200
1 - 98 For Position Accounts
1 - 200 For standard Internal Accounts
Invalid if the MASTER.ACCOUNT is set
MERGE.NCU
MNEMONIC
Specifies an alternative method of referencing the Account.
The Mnemonic code rather than the Account ID may be used at any time to reference the Account details.
Validation Rules:
Up to 10 type MNE (uppercase alpha or numeric or '.') characters. (Mandatory for Internal Accounts, otherwise optional input. No default value. No Mnemonic is generated for automatically opened Accounts, it must be loaded as part of the first amendment.)
(1) The Mnemonic code must be unique (no other Account may have the same Mnemonic value).
MULTI.CURRENCY
This field indicates if the account supports multi-currency functionality
Validation Rules:
Can be set to 'YES' or 'NO'
MV.ALERT.RES1
MV.ALERT.RES2
MV.ALERT.RES3
MV.ALERT.RES4
MV.ALERT.RES5
MV.ALERT.RES6
NEXT.ACCT.CAP
If this account has an active ACCT.CAPITALISATION record then the next capitalisation date will be stored here, and in the GROUP.ACCOUNT key. This field is updated whenever the relavant ACCT.CAPITALISATION record is updated, or whenever the frequency fields on ACCT.CAPITALISATION are
recycled during the capitalisation process.
No Input Date field.
NEXT.AF.DATE
No Input field, contains the next exposure or value date for an entry for this account that lies outside the current available dates window. This is used by the start of day processing that updates the available balance fields. If the NEXT.AF.DATE becomes due then the relevant forward entries
are incoporated into the available balances.
NEXT.EXP.DATE
The date of the next forward exposure movement for the Account.
NEXT.STMT.DATE
Next due date of FQU1 ACCOUNT.STATEMENT. This will be used to update the STMT.PRINTED. Multi-valued to cater for multiple frequencies.
Validation Rules:
EXTERN field.
NOSTRO.CCY
ONLINE.ACTUAL.BAL
Contains the current Actual Balance of the Account. This is the same as the actual balance at the start of day (Open Actual Balance) plus the value of all fully Authorised entries since the start of day.
Validation Rules:
Standard amount format. (Internal field.)
ONLINE.CLEARED.BAL
Contains the current Cleared Balance of the Account. This is the same as the cleared balance at the start of day (Open Cleared Balance) plus the value of all fully Authorised entries since the start of day, except any credit or reversal debit entries with future Exposure Dates.
For credit and reversal debit entries with Exposure Dates in the future, this field is updated at start of day, on the appropriate date, by the program FWD.EXPOSURE.
Validation Rules:
OPEN.ACTUAL.BAL
Contains the Actual (uncleared) Balance or 'Ledger Balance' of the Account as at the start of the day.
Validation Rules:
OPEN.ASSET.TYPE
Contains the ASSET.TYPE for the ACCOUNT as at the start of the day. For new ACCOUNTS the ASSET.TYPE will be set to 'NILOPEN', when the first accounting entry is raised.
OPEN.AVAILABLE.BAL
Contains the same balance as the Open.Cleared.Bal, which is the cleared balance of the Account as at the start of the day. This includes the value of all entries over the Account except any credit entries or reversal debit with Exposure Dates in the future.
Validation Rules:
OPEN.CATEGORY
Contains the accounts category as of last night, i.e. if this has been changed today, then the value here will be the category as of last night. For new account record inputs, then this will be updated on line and reflect the opening category.
Validation Rules:
1 - 5 Character Category Code. (Internal System field.)
OPEN.CLEARED.BAL
Contains the Cleared Balance of the Account as at the start of the day. This includes the value of all entries over the Account except any credit entries or reversal debit with Exposure Dates in the future.
Validation Rules:
OPEN.VAL.DATED.BAL
Contains the accounts value dated balance calculated in last nights batch run. Defined as all entries across the account with a value date up to but not including today.
Validation Rules:
Standard Amount Format. (Internal System field.)
OPENING.DATE
The date when the account was opened.
Validation Rules:
11 character DATE.
OPERAND
Standard T24 operand.
Associated multi value field of Event
Validation Rules:
Only the following values are allowed
equals, matches, not equal to, greater than, greater than or equals, less than, less than or equals, between, not between, contains, not containing, begins with, ends with, does not begin with, does not end with, changed, changed to, changed from, goes below, goes above.
ORIG.CCY.PAYMENT
This field indicates whether the payments to be sent through delivery should remain in the national currency or rather be converted to the AUTO.PAY.ACCT accounts currency.
Validation Rules:
Can be set to 'YES' or 'NO'.
ORIGINAL.ACCT
This field holds for display purposes only the the ORIGINAL account number when an account conversion has taken place.
MV field can have several account numbers
Validation Rules:
OTHER.OFFICER
Identifies any other Account Officers who may have some involvement with the Account.
This field specifies any other Account Officers who may have some involvement with the Account, for example, the Officer(s) who may be contacted when the main Officer is unavailable.
For Customer Accounts, this field should be entered only when a different Officer from that held for the related Customer is required.
Validation Rules:
1-4 numeric character Account Officer code. Multivalue field. (Optional input. The system will default to the Officer(s) held for the related Customer, although these will not be generated in this field.)
It must be an existing code on the DEPT.ACCT.OFFICER table.
No duplicate Account Officer codes are allowed.
OUR.EXT.ACCT.NO
Defines our 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 only.
Validation Rules:
Up to 34 type A (alphanumeric) characters. (Optional input if ID Account is Nostro Account, otherwise not allowed.)
OVERDUE.STATUS
If the contract is overdue, then this field identifies the status of the underlying PD contract.
Validation Rules:
No input. system updated.
OVERRIDE
Contains details of any overrides applicable to this Account.
Conditions where overrides will be required include the following:
- New input or change of Compensation Account or Liquidation Account referring to an Account which is flagged pending closure (Posting Restriction in the range 80-89).
- New input or change of Limit Reference referring to a Limit which is already exceeded.
Validation Rules:
Up to 35 type A (alphanumeric) characters. Multivalue field. (Internal field.)
PARENT.ACCOUNT
This field specifies the parent Summary account for this account. Any Statement Entries passing through this account will be automatically duplicated to the parent Summary account
Validation Rules:
Valid Account number
PARENT.BV.DATE
This field holds the date of the latest internal restructuring of the network of Parent accounts above this account. i.e. the latest date when the network of Parent accounts above this account was changed
If the back value date of the Statement Entry is prior to this date then the Statement Entry copied to the Parent Account will be adjusted to this date
The original Statement Entry will not be impacted
Validation Rules:
Standard Date Format
PASSBOOK
Determines if the account has a passbook.
Only valid for accounts with a savings category. See ACCOUNT.CLASS. If set to "Y" all account statements are suppressed. Default NO.
Validation Rules:
Y or NO.
PENDING.ID
This field will store the ids that will point to the AC.PENDING file containing details of the debit interest and/or charges pending on the account.
Validation Rules:
PORTFOLIO.NO
This field contains the id to any SEC.ACC.MASTER records that are linked to this account.
Validation rules
EXTERN field
POSITION.TYPE
Identifies the Type of Foreign Exchange Position which will be updated as a result of movements over this account.
Validation Rules:
2 type SSS (uppercase alpha) character Position Type code. (Optional Input. Default is TR.) Cannot be changed.
It must be an existing code on the Position Type Table (FX.POS.TYPE in General Tables).
POSTING.RESTRICT
Identifies any restrictions for posting entries that are imposed on the Account.
An override will be required to accept any entry which meets the conditions of a Posting Restriction.
Posting restrictions in the range 80-89 are used to indicate Accounts which are flagged pending closure.
Restrictions in the range 90-99 indicate Accounts which will be closed automatically as soon as all Balances are zero. These restrictions are entered via the ACCOUNT.CLOSURE file and once a value on the range 90 - 99 is in this field it becomes NOINPUT and may only be removed by reversing
the ACCOUNT.CLOSURE.
Validation Rules:
1 to 4 numeric characters Posting Restriction code, based on EB.OBJECT. (Optional input. No default value.)
NOINPUT when contains a value in the range 90 - 99.
It must be an existing code on the POSTING.RESTRICT table.
For Account Closure (restriction in the range 90-99) the following rules apply: a) The Account may not be the Liquidation Account for any other Account(s). See ACCOUNT.LIQUIDATION for further details. b) The Account may not be the Main Account of a group of Accounts where balances are
netted for interest and charges. See ACCOUNT.COMPENSATION for further details. c) Field 17, INT NO BOOKING must not contain 'SUSPENSE'. d) There must not be any entries on the FWD.ENTRY file for the Account.
PREMIUM.FREQ
Specifies the next date and subsequent frequency of the application of premium interest.
The first part of the field specifies the next application date for premium interest, the 2nd part specifies the frequency of premium interest applications.
The next date is updated automatically by the system on each application day.
The allowable frequencies are:
FREQUENCY NEXT DATE
Mnndd Every nn months on the dd day
When amending this field manually, if the next date is omitted, the system automatically generates it as follows:
FREQUENCY NEXT DATE
Mnndd (Every nn months on the dd day) If today's date is less than dd, the next date is day dd in nn months from last month, otherwise it is day dd in nn months form the current month. If this date does not exist (e.g. 30th February) the previous day is assumed (28th or 29th February).
Validation Rules:
Either of the following combinations may be entered : DATE & FREQUENCY or ONLY DATE or ONLY FREQUENCY
This field is in two parts. 1) Next Application Date: 1-9 Date characters. Default value calculated by the system depending on application frequency. (Optional Input). 2) Application Frequency: 1-5 type SS (uppercase alpha or numeric, first character alpha) characters (Mandatory input.)
The field can be specified only if the capitalisation frequency on the corresponding SAVINGS.PREMIUM record is blank.
The Frequency must be one of those listed above.
PREMIUM.TYPE
Defines the type of premium(s) that was/were capitalised on the date in the corresponding field CAP.DATE.PREM This field is updated automatically by the system.
Validation Rules:
The premium type must exist on the SAVINGS.PREMIUM file.
PRINTING.CODE
The field is used to define if cheque book is to be printed by bank or by customer
RECO.TOLERANCE
Identifies the tolerance amount allowed when matching items in Nostro Reconciliation.
This field may either be set to 0 if tolerance is not required or an amount in the currency of the account.
Validation Rules:
Standard amount format
RECONCILE.ACCT
Specifies whether the Account is to be reconciled.
Validation Rules:
Y = Yes (No input assumes NO) (Must be Y for Nostro Accounts, otherwise optional input)
REDUCING.LIMIT
Indicates whether the behaviour of the limit currently being utilized by the account is either Reducing or Non-Reducing.
Validation rules:
Allowed only for arrangement accounts
Allowed only if the limit attached to the account is of type "NEUTRAL"
Options field. Valid values are: Y, N and NULL
Y - Reducing type
N / NULL - Non-Reducing type
REF.DATA.ITEM
This field holds the integration data item
Validation Rules:
Integration Data item will be fixed names agreed by the integration teams. Values will not be validated, any text value can be supplied. The system must ensure that duplicate data items are not defined in the same application record.
REF.DATA.VALUE
This field holds the data value
Validation Rules:
When there is a value in field REF.DATA.VALUE, and the corresponding REF.DATA.ITEM is blank, then the record should not be able to commit. There is no requirement to enforce any format in T24. it will be held as text values and will assume that data is validated in the other system
REFERAL.CODE
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 and sign, or the balance of the Account.
Validation Rules:
1-6 numeric character Referral code. Multivalue field. (Optional input. No default value.)
It must be an existing code on the REFERAL Table (Referral).
Duplicate codes are not allowed.
RELATION.CODE
This field signifies a relationship that the JOINT.HOLDER field has with the account in view.
If not inputted, will be defaulted with the value from the RELATION.CUSTOMER table, if there exist a relation between the two customer
If entered the following validation takes place
Validation Rules:
The field must contain a valid relation code established on the RELATION file.
The entered relation code must be the reverse relation with the account customer, if there is any relation specified in customer record
This field cannot be entered if the JOINT.HOLDER field has not been entered.
This field must be entered if the JOINT.HOLDER field has been entered.
REQUEST.ID
Holds the ID of EB.ALERT.REQUEST application.
Whenever, T24 Alert setup is made, the user has to create a record in EB.ALERT.REQUEST (EAR) application pertaining to the ACCOUNT record by which the EAR record ID will get automatically updated in ACCOUNT record.
S.BUNDLEID
S.DAYS
S.LINKTYPE
S.SIMULATED.CCY
SAM.ID.HIST
This field gets populated when ACCOUNT.NO field in SEC.ACC.MASTER is removed and Remove reason is 'closure'
Validation Rules:
Valid Portfolio No
SB.GROUP.ID
This field will contain the shared balances group id, which is used by the cash pooling functionality, during the online overdraft checking to determine if an account (with it set) has additional overdraft checking on other accounts in its group
Validation rules
No Input
SECONDARY.LIMIT.AMT
Field to define Secondary Limit Amount to be used for the purpose of Secondary Limit Check.
The Secondary Limit Amount defined in this field will be represented in repective account currency
Validation Rules:
Optional Field
Standard amount format
SERIAL.NO.FORMAT
This field defines the format of the serial number of a particular stock, e.g. American Express USD Travellers Cheques. The serial no input on a TELLER transaction will be validated against this field.
Validation Rules:
Optional input field.
No change allowed once defined.
Valid input must be a combination of 'A', 'N', 'X' and '.' 'A' - any alphabetic characters (mandatory). 'N' - any numeric characters (0-9). 'X' - any alphanumeric characters (optional). '.' - the mask character.
One and only one group of 'N's must be specified.
At least one 'A' must be defined next to the 'N's if the 'N's are not defined at the beginning nor at the end. '.' can only be defined with the Ns.
Examples: XAXX.NNN.NNN - at most 4 alphanumeric followed by 6 numeric. ANNNNNNNNA - 1 alpha followed by 8 numeric followed by 1 alpha. XXNNN.NNN.NNN - at most 2 alphanumeric followed by 9 numeric. XAXNNNNNXXX - INVALID because no 'A' defined next to the 'N's. X.ANNN.NNN.AA -
INVALID because a '.' is defined between 'X' & 'A'.
SHADOW.ACCOUNT
Holds the value YES or NULL.
While inputting new arrangement for account creation, system updates this field based on the value specified in the product condition of Account property class.
If this field has value 'YES' then the balance details of this account is not maintained within T24 and it will be held by an external DDA system. Within T24, only static information of this account would be maintained.
If this field has NULL value, then it is like a normal T24 account, so the balances would be maintained by T24 for this type of accounts.
VALIDATION RULES
Should be either YES or NULL only. Default value is Null.
SHORT.TITLE
Specifies the abbreviated title of the Account.
This field can be used for reporting and enrichments in different languages.
Validation Rules:
Up to 35 type A (alphanumeric) characters. (Mandatory for Internal accounts, otherwise optional input. Default is the Short Name from the Customer record.)
SHOW.TILL.ACS
SINGLE.LIMIT
If Single limit is set to
"Y" then only one account can be attached to a limit. (Attaching multiple accounts to single limit is restricted)
"N" then multiple accounts can be attached to a limit. (All the respective accounts to be defined "N" in single limit field)
If field is blank then, it is treated as "N"
Validation Rules:
Optional Input
Defaulted if defined in ACCT.GROUP.CONDITION ; allowed for manual change
Valid input are Y/N
START.DATE
START.YEAR.BAL
Holds the cleared balance at the start of the year.
Validation Rules:
19 numeric characters.
STMT.RECO.WITH
Identifies the Internal Account to which the ID account number is reconciled.
This field is used to reconcile Internal accounts within Nostro Reconciliation. The account entered may not be a Nostro account and must be of the same currency as the ID account number.
Validation Rules:
2-16 numeric characters Account Number or 3-10 type MNE (uppercase alpha or numeric or '.') character account mnemonic (Not allowed for Nostro Accounts, no default value)
Must be an existing Account Number.
Account number must not be equal to ID account number.
Account must be the same currency as ID Account number.
STOCK.CONTROL.TYPE
This field defines the type of control required in the stock control system.
Both denomination and serial no. will be required on a TELLER transaction if SERIAL is specified.
If DENOM is specified then the denomination field is mandatory on a TELLER transaction.
Validation Rules:
Optional input field.
Valid input is either DENOM or SERIAL.
TAX.AT.SETTLE
Reserved for future use.
TAX.SUSPEND
Reserved for future use.
TOTAL.PENDING
This amount is the total amount that due on the associated AC.PENDING record pointed to by the field PENDING.ID.
Validation Rules:
TRAN.LAST.CR.AUTO
Contains the Transaction code of the last automatically generated credit entry passed to this Account.
If more than one credit entry is generated automatically on the same day, details of the largest one are stored here.
Validation Rules:
(Internal field updated during end of day processing.)
TRAN.LAST.CR.BANK
Contains the Transaction code of the last bank generated credit entry passed to this Account.
If more than one credit entry is generated by the bank on the same day, details of the largest one are stored here.
Validation Rules:
TRAN.LAST.CR.CUST
Contains the Transaction code of the Last Customer generated credit entry passed to this Account.
If more than one credit entry is generated by the Customer on the same day, details of the largest one are stored here.
Validation Rules:
TRAN.LAST.DR.AUTO
Contains the Transaction code of the last automatically generated debit entry passed to this Account.
If more than one debit entry is generated automatically on the same day, details of the largest one are stored here.
Validation Rules:
TRAN.LAST.DR.BANK
Contains the Transaction code of the last bank generated debit entry passed to this Account.
If more than one debit entry is generated by the bank on the same day, details of the largest one are stored here.
Validation Rules:
TRAN.LAST.DR.CUST
Contains the Transaction code of the last Customer generated debit entry passed to this Account.
If more than one debit entry is generated by the customer on the same day, details of the largest one are stored here.
Validation Rules:
TX.BEN.NUM
Holds the Benefit Number of the account.
TXN.AMT
TXN.CODE
VAL.DATE
VALUE
Value to be tested.
Associated multi value field of Event.
This field gets populated while creating a record in EB.ALERT.REQUEST.
VALUE.DATE
Contains the value date of future credit and debit movements to the account for the purpose of cash flow processing.
Fields CREDIT.MOVEMENT to VALUE.DATED.BAL indicate all debit and credit movements to the account valued on the date in this field.
Cash flow Balances are held here for all forward dated and value dated account movements up to the number of calendar days forward from today as specified on the 'CASH FLOW DAYS' field on the ACCOUNT.PARAMETER file.
If a value dated entry (not forward dated), is made to the account for a value date that is past the cash flow window, then this value date will replace the old window end date and all cash flow balances will be shown up to this new date.
Validation Rules:
Standard Date Format. (Internal Field) This field forms a multi value set with fields VALUE.DATE and field VALUE.DATED.BAL.
VALUE.DATED.BAL
This field is the net of fields CREDIT.MOVEMENT and DEBIT.MOVEMENT plus the previous days VALUE.DATED.BAL and indicates the accounts WORKING.BALANCE on the date specified by field VALUE.DATE above.
This multivalue field will display the working balance for all future dates that fall within the cash flow window (as specified on the ACCOUNT.PARAMETER file field CASH.FLOW.DAYS), and that also have forward debit and credit movements on the date specified by field VALUE.DATE above.
Validation Rules:
Standard Amount Format. (internal Field) This field forms a multi value set with fields VALUE.DATE and field VALUE.DATED.BAL.
WAIVE.LEDGER.FEE
Specifies whether Ledger Fees for the Account are to be waived.
Ledger Fees are normally applied monthly, quarterly or six monthly as specified in the COMPANY record.
The charges applicable are specified in the GENERAL.CHARGE record referred to either in the GROUP.DEBIT.INT record or, (if there is one), in the ACCOUNT.DEBIT.INT record for this Account.
Using this field, it is possible to waive the charges defined in the Group Debit Interest record for specified Accounts without having to define separate interest conditions for those Accounts.
For further information about account groups for interest and charges details, see field CONDITION.GROUP in this record.
Generic charges i.e(charges collected from IC.CHARGE) will be waived, if this field is set to 'Yes' during ACCOUNT.CLOSURE process as well as for normal processes(Capitalization process).
Validation Rules:
Y = Yes (Optional input. No input assumes No.)
WORKING.BALANCE
Contains the present balance of the Account which is used for checking by the Limits System etc. At the start of day this is the same as the cleared balance (Online Cleared Balance).
For Nostro and Internal Accounts, it is updated by all entries when they have been fully Authorised. For other Customer Accounts it is updated by debit entries when they are Validated and by credit entries when they have been fully Authorised, except for any credit or reversal debit entries
with Exposure Dates in the future.
For credit and reversal debit entries with Exposure Dates in the future, this field is updated at start of day on the appropriate date, by the program FWD.EXPOSURE.
Validation Rules:
T24 Common HelpText Fields

Account T24

Загружено:

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

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

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

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

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

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

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

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

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

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

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

Account T24

Загружено:

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

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

ACCOUNT

Вам также может понравиться