Introduction to Accounts

The usage of some main fields in this application are explained in the following table.

Field Name	Usage
Cash Flow Days	Specifies the number of calendar days forward for which the cash flow balances are to be maintained for the purpose of accounting overrides and cash flow processing. The number of days entered here determines the window period that cash flow balances are to be maintained on each account record. Each forward dated entry generated for an account impacts the cash flow balances, if the date of the entry falls within this period. If the number of days entered is 10, then any forward dated entry raised online that has the value date less than 10 calendar days from current date will update the accounts cash flow balances. If this update causes either a limit to be exceeded or an unauthorised overdraft to occur, then an override message appears on the transaction input. All entries raised online that fall outside the window do not update the account balances immediately and no override messages appear. But when their value dates fall within the window, the start of day process (SOD.CASH.FLOW) updates the account cash flow balances. If an exception occurs at this stage, then the CASH.FLOW.EXCEPTION table is updated to indicate this. If the value is not entered in this field, then only the nostro accounts have cash flow maintained and a default of 10 calendar days is used for this.
Value Dated Acctng	A switch to set value dated accounting as On or Off or Trade Dated General Ledger (TDGL). If a value dated accounting system is required, then this field must be set to Y. In trade dated accounting system, the cash based transactions update the customer’s account and the bank’s position on the date in which the transaction is processed in the system, irrespective of the value date assigned to the transaction. In value dated accounting system, the cash based transactions update the customer’s account and the bank’s position on the value date assigned to the transaction. It is held as off balance sheet until the value date. In TDGL accounting system, the cash based transactions update the customer’s account and the bank’s position on the value date assigned to the transaction. It is held under payable or receivable until the value date. Cash based transactions follow the accounting treatment based on this setup. However, the accounting treatment can be switched from one system to another and the system permits any of the following switch. Switching of Accounting System Treatment of cash based transactions can be switched from one system to another, any combination of the setup is possible. Original Accounting Setup Target Accounting Setup Trade dated Value dated Trade dated Trade dated GL Value dated Trade dated Value dated Trade dated GL Trade dated GL Trade dated Trade dated GL Value dated The new accounting system switch applies to new transactions only. The existing cash based transactions with a future date follows the setup applied when the transaction were raised. The Tdgl Details field in the STMT.ENTRY application holds the details of the accounting method followed for the transaction. NOTE: Exceptions to the above is SEC.TRADE – Actual Settlement: If contract input is in existing setup and authorized in the modified setup, then the system follows the modified setup.
Use Pay Receive	This field is used to flag the suspense processing at system Level, in the case of value dated or TDGL accounting setup. Under these accounting setup, the value of the transaction is suspended in a temporary account till the split value date is reached. The allowed values are : Yes – Suspended to GL accounts pay or receive as special entries and reported as on-balance sheet item in the general ledger (GL) report. No – This is the default setup where the suspense processing posts the entry to the internal suspense account.
Pay Rec Allwd	This field works in conjunction with Use Pay Receive. It is used when a customer wants to decide if payable or receivable are to be reported with account attributes or against underlying customer attributes based PR.CUSTOMER.BALANCE application. Value in this field should be valid record ID of AC.DEFINE.PAY.RECV.ALLOWED application. This field is available at different levels such as System level, System Id (sub-system) level, Category level and System ID with Category level. In the AC.DEFINE.PAY.RECV.ALLOWED application, the users can create their own records using any of the following options in Pay Recv Options field. The ID of the application record can be a meaningful alpha-numeric name. Broker – This option decides the customer to whom the payable or receivable is to be booked in the PR.CUSTOMER.BALANCE. If this option is set, the payable or receivable is booked against the third party customer (for example, broker) passed from the application. If this option is not set, the payable or receivable is booked against the customer passed in the original entry from the underlying application. Contract – If this option is selected, all the payables or receivables are reported under the PR.CUSTOMER.BALANCE. Customer – If the target account passed from the underlying application is a customer account and the Customer option is set, then the payables or receivables are reported under PR.CUSTOMER.BALANCE. Internal – This option works similar to Use Pay Recv set to Yes. If the entry is posted as an internal (suspense) account and the target account is passed from the application, then the original STMT entry to internal (suspense) account is converted to special entry with asset type as PAYSUS or RECEIVESUS. Nostro – If the target account passed from the underlying application is a NOSTRO account, and the Customer option is set, then the payables or receivables are reported under PR.CUSTOMER.BALANCE. NULL – If no option is set, then the system continues to work as usual.
Val Date Sys Id; Val Date By Sys; Use Pay Rec Sys	Enables the definition of accounting treatment for specific cash-based applications, where it is different from the default accounting treatment. If the default accounting system is trade dated, for the application mentioned in Val Date Sys Id, a different accounting system can be defined. For example, if SEC.TRADE is to follow TDGL accounting system, the Val Date Sys Id is defined as SCTR and Val Date By Sys is defined as TDGL.The Use Pay Rec Sys field can be flagged as Yes or No, which is used in the suspense processing for the specific application.
Vd Cat Start; Vd Cat End; Val Date By Cat; Use Pay Rec Cat	Enables the definition of accounting treatment for specific category or range of categories, where it is different from the default accounting treatment and application specific (if defined) accounting treatment. The category level definition takes precedence over the system level and application level definition. The Use Pay Rec Cat field can be set to Yes or No, which is used in the suspense processing for the specific category.
Vd Cat Sys Id; Vd Cat Sys Start; Vd Cat Sys End; Val Date By Cat Sys; Use Pay Receive Cat Sys	If the accounting system for specific categories of an application is different from the default accounting system, it can be setup using these set of fields. The application can be defined in Vd Cat Sys Id, the category or range of categories can be defined in the Vd Cat Sys Start and Vd Cat Sys End fields. The accounting system applicable to this setup are defined in the Val Date By Cat Sys field. The Use Pay Receive Cat Sys field can be set to Yes or No, which is used in the suspense processing for the specific category.
Entry Category; Sus Category; Suspense Txn In; Suspense Txn Out; Suspense History	The format of Entry Category can either be CATEGORY-FX.POS.TYPE or CATEGORY, which determines the suspense account to be used when operating in a value dated accounting system. If the position type for the Entry Category does not exist, then the entry category alone is used to determine the suspense category. Else, the default suspense category is used. When a split value dated transaction is processed in a value dated accounting system then the first leg is balanced against a suspense account. This is washed out when the second leg reaches its value date. The suspense account that is used is determined by the category of the second leg entry. The Entry Category field and its associated field Sus Category defines this relationship. Example XX.1 ENTRY.CATEGORY YY.1 SUS.CATEGORY 19998 XX.2 ENTRY.CATEGORY 5000-XX YY.2 SUS.CATEGORY 19999 Entry Category is a start of range value. Hence in this example, second leg entries with a category in the range 0 - 4999 uses account LCL199980001 (where LCL is the local currency code) and entries with a category 5000 and above uses LCL199990001 for suspense processing. To define a default suspense account for all the entries, configure as shown below: XX.1 ENTRY.CATEGORY YY.1 SUS.CATEGORY 19998 The purpose of defining different suspense category is to allow the splitting of suspense movements, for value dated accounting, within the CRB. For example, it is possible to report suspense entries for nostro accounts separately from suspense entries for current accounts.
Sys Code; Nostro Default; Def Override; Use First Acct; Default Order	These set of fields are used for defaulting the settlement nostro account applicable to the transaction defined in Sys Code field. The Sys Code field is a combination of Application-Nature of transaction, for example, LD-PRIN or LD-INT. These values must be defined upfront in AC.SYS.CODES application. The Nostro Default field is used to specify how settlement accounts are defaulted when using a nostro account for the associated Sys Code. A null value implies that the nostro account is always defaulted. The following are the options in this field: AGENCY – Defaults only when agency conditions exist. NONE – No nostro account is to be defaulted. The Def Override field defines whether an override is required when the default account number does not match the account number entered on the deal. Additionally, if the account with bank, intermediary bank or beneficiary account number differs from the default derived from the information on the agency file, then an override is raised if this field is set to Yes. The Use First Acct field defines whether an account is to be defaulted when more than one possible default account exists. The following options are available in this field: Yes – First account of the customer in any company is defaulted. No – If more than one account is present in the current company, then no defaulting takes place. In a multi-book setup, the following additional options are available for this field: CUR – First account of the customer in current company is only defaulted. FRS – First account of the customer in the current company as first choice followed by first available account in any company is defaulted.
Cheque Register; Chq Dep Txn; Def Coll Susp; Chq Col Txn; Chq Ret Txn; Def Ret Susp; Return Txns; Return Susp Cat	The Cheque Register field indicates whether or not the cheque issue and management functionality within Temenos Transact has been activated. The Yes or No value entered in this field controls the defaulting of cheque type in DATA CAPTURE (DC) or FUNDS TRANSFER (FT) or TELLER (TT) application as well as payment stop processing. The list of transaction code for cheque on collection, clearing and returned cheque and the corresponding suspense accounts where the value of cheque needs to be parked in the clearing process can be defined in these set of fields.
Net Od Appl; Net Od Override; Net Locked Override	The Net Od Appl field specifies the Temenos Transact application for which debit and credit entries to an account in a transaction must be netted for displaying the overdraft and cash flow overrides. The allowed applications are LOANS AND DEPOSITS (LD), TELLER (TT), COLLATERAL (CO), FUNDS TRANSFER (FT), ARRANGEMENT ARCHITECTURE (AA) or ALL. When this field is set to ALL, the functionality is applied for all transaction irrespective of the application. The pre-condition for the suppression of overrides is to set the Net Od Override field as Yes. If Net Od Appl holds the value ALL, the system does not permit any other multi-value to be input. Either applications are manually input in a multi-value block or ALL value is used. For example, if Net Od Appl field is set to ALL and Net Od Override field is set to Yes and a transaction is made using the same account as both debit and credit account, no override is generated for any excess amount. Suppression of Unnecessary Overrides: If a single contract creates both credits and debits to an account, if the net effect of the contract is to credit the account, it is possible to suppress the override generated for the debit side of the transaction. Example If a discounted loan is arranged for a customer, whereby the customer has a balance of £10, receives a credit of $1000 for the loan, but also a debit of $100 for the upfront payment of interest.  The system usually generates an override specifying that the customer is debited $100 and the customer is being overdrawn by $90.  However, it is possible by configuring the fields Net Od Appl as LD and Net Od Override as Yes in the ACCOUNT.PARAMETER to net off the differences, so as the credit of $1000 exceeds the debit of $100 and the override is suppressed.
Retain Ac Balances	Defines whether balances need to be maintained in ACCOUNT or not. When set to Yes the balances are updated in ACCOUNT and EB.CONTRACT.BALANCES. When set to N the balances are not updated in ACCOUNT, but updated only in EB.CONTRACT.BALANCES. Default value is Yes. NOTE: Changing this setup from Yes to No clears the existing account balances automatically.
Booked Balance	Defines which booked balance is recorded in the STMT.ENTRY record when the transaction is booked. The following are the options available in this field. Online Actual Bal – Records the account balance from the GL perspective, this means that future dated movements are not included. Traded Dated Gl Bal – Records the account balance from a customer perspective, which means that future dated movements recorded as PAY or RECEIVE are included. NOTE: The enhanced transaction search uses the value in this field to display the output in Booked Balance column of the enquiries

The ACCT.GEN.CONDITION application defines the grouping condition for accounts. The ID format of this application is <NUMERIC GROUP CODE>. For example, 1.

The use of these category codes along with CUSTOMER attributes like SECTOR and RESIDENCE enable further grouping of accounts based on the business needs. These attributes and their order of priority is defined in the CONDITION.PRIORITY application for an ACCOUNT record.

Also, the grouping criteria is defined in this application. Accounts satisfying the criteria fall under the respective group. Group specific interest and charge conditions and other privileges can be defined, which are applicable for all accounts falling under the group. Account specific interest and charges can also be defined. 

The ACCT.GROUP.CONDITION application defines the rules for group of accounts. The ID format of this application is <GROUP ID><CURRENCY>-<DATE>. For example, USD 1.

Rules for notice withdrawals, account violations, deferring interest and charges, rounding rules for interest and premium interest applicable to accounts belonging to a group and specific currency are defined in this application. Further, the record ID for this parameter application may be suffixed with a date in the YYYYMMDD format. This date specifies that the record is a change request for the condition group and currency combination specified in the first part of the key. The request records are processed in the Close of Business (COB) processing and the new values of the parameters are passed into the active record using the values from this request record.

The following fields are used to configure operational restrictions using the ACCT.GROUP.CONDITION.

The GROUP.DEBIT.INT (GDI) application defines debit interest conditions. The ID format of this application is <GROUP ID><CURRENCY><EFFECTIVE DATE>. For example, 1USD20170316.

The GDI application allows the user to specify the calculation method of debit interest for groups of accounts and provides the link to the GENERAL.CHARGE application (where the charges applicable to the same groups of accounts are specified). The following are the features of this application.

• Interest conditions are currency specific.
• Interest can be calculated on a daily, average or highest balance basis using the value dated balances.
• Flexibility to define a second interest on the account with different capitalisation frequency.
• Supports different types of interest basis.
• Rates can be fixed or floating (basic rate plus or minus a margin).
• Different rates can be specified for different balance levels and can 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.
• In a multi-tiered interest structure, the calculation type could be band or level.
• 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 can be charged when the limit has been exceeded. In this case, a maximum of two rates can be specified.
• Negative interest rates can be defined based on the functionality.
• Tax on interest can be defined.

The GROUP.CREDIT.INT (GCI) application defines the credit interest conditions. The ID format of this application is <GROUP ID><CURRENCY><EFFECTIVE DATE>. For example, 1USD20170316.

The GCI application allows the user to specify the calculation method of credit interest for groups of accounts. The following are the features of this application.

• Interest conditions are currency specific.
• Interest can be calculated on a daily, average or minimum balance basis.
• Flexibility to define a second interest on the account with different capitalisation frequency.
• Supports different types of interest basis.
• Rates can be fixed or floating (basic rate plus or minus a margin).
• Different rates can be specified for different balance levels and can 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.
• In a multi-tiered interest structure, the calculation type could be band or level.
• Tax free interest amount and applicable tax on interest can be defined.
• Possibility to mark the calculation of credit interest only to offset the debit interest. In this case, the capitalisation date of credit and debit interest must be the same.

The GROUP.CAPITALISATION application is related to the interest capitalisation frequency. The ID format of this application is <GROUP ID>. For example, – 1.

The interest and interest related charge capitalisation frequency is defined in this application. The date and frequency for debit and credit interest capitalisation can be different. Also, the second interest (DR2 and CR2) capitalisation date and frequency can be different from the first interest (DR and CR) capitalisation date. The next capitalisation date is cycled automatically based on the frequency given for the respective interest. This is group specific and applicable to all accounts in the group irrespective of the operational currency.

Read GROUP.CAPITALISATION for more information.

The ACCOUNT type records provide the CATEGORY code information which is used for constructing an internal account number (like netting suspense account). The CATEGORY code must be in the range 10000 to 19999.

Click here to view the list of existing account class records with type as ACCOUNT.

The CLASS type records are used to identify a group of accounts (like nostro) by matching the account details against those held in the ACCOUNT.CLASS application. The Category and/or Sector must be defined for this type.

Click here to view the list of existing account class records with type as CLASS.

The PL type records are used to identify the profit and loss category to be checked or used for specific functionality by certain applications of Temenos Transact (like DX commission earned but not received).

Click here to view the list of existing account class records with type as PL.

The account number on customer account is a number up to 16 characters. The format of the number can be validated if required, for example, by using check digits or the automatic inclusion of the customer number. The length and check digit type used for an account is defined in the following fields in the COMPANY application.

• Acct Checkdig Type
• Acc Bkno Prefix
• Account Mask

For extended account numbers longer than 16 characters, the input length must be defined in the Max Length field in the EB.OBJECT application. The Acct Checkdig Type field identifies the check digit calculation method for the company being entered. The following values are accepted in this field.

The validation rules that are accepted are 1, 2, 3, 4, 5, 6, 99, @routine name and blank. This field is input mandatory when LocalCurrency field starts with BE or LU.

Automatic Generation of Customer Account Number

The account number can be generated automatically on creation, by pressing the Function key (F3), based on the following configuration:

• ACCOUNT application must be included in #PGM.AUTOM.ID application in the COMPANY record for automatic account number generation at the time of account creation.
• The AUTO.ID.START application contains the information pertaining to the starting key from which auto numbering must start and the application to which the auto numbering is to be applied.
• The system considers the length and check digit logic from the COMPANY record and applies it to the start number.

The format of an internal account depends on how the environment is setup (that is, single company, multi-company or multi-book) and what the account is to be used for (that is, cash account, suspense account, inter-company account or position accounting).

The following are the different internal account structures that can be setup.

Multi-book

In a multi-book environment, the simple internal account number format is CCYCCCCCNNNNBBBB, where:

• CCY is the swift currency code of the account, for example EUR, USD.
• CCCCC is a category code in the range 10000 – 19999.
• NNNN is a sequential number in the range 0001– 9999.
• BBBB is the sub division code of the company to which the account belongs (Sub Division Code is a field available in the COMPANY record).

The simple internal account number is formed as USD1490000010002, where:

• USD is the currency of the account
• 14900 is the internal account category
• 0001 is the sequential number
• 0002 is the sub division code of the company to which the account belongs.

In the case of internal accounts used for cash handling, the sequence number in the ID is the TELLER.ID of the cash transaction.

The cash account is formed as USD1000100250002, where:

• USD is the currency
• 10001 is the category for cash account
• 0025 is the TELLER.ID
• 0002 is the sub division code

Multi-company

In multi-company setup, the internal account format is the same as that of the multi-book for simple internal account, cash handling account and position account.

Single company

In single company setup, the internal account number format is CCYCCCCCNNNN, where:

• CCY is the swift currency code of the account, for example EUR, USD.
• CCCCC is a category code in the range 10000 - 19999.
• NNNN is a sequential number in the range 0001 - 9999.

A simple internal account ID in single company is EUR120010005.