TEMENOS T24

ACCOUNTS

User Guide

Information in this document is subject to change without notice.

No part of this document may be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without the express written permission of TEMENOS Holdings NV.

Copyright 2005 TEMENOS Holdings NV. All rights reserved.

Accounts

Table of Contents
Introduction.............................................................................................................................................. 3
Application Overview ........................................................................................................................... 3
Overview of Input and Processing ....................................................................................................... 3
ACCOUNT.PARAMETER ................................................................................................................ 3
ACCOUNTING..................................................................................................................................... 5
Enforcing balanced accounting entries ............................................................................................ 5
Client Account .................................................................................................................................. 8
Internal Accounts............................................................................................................................ 10
Account Number Format ................................................................................................................ 11
Account Input ................................................................................................................................. 17
Contingent account ........................................................................................................................ 18
Set-up of Contingent Accounts ...................................................................................................... 19
NOSTRO Accounts ........................................................................................................................ 23
Account balances ........................................................................................................................... 24
Locking of Funds (Blocked or Held Amounts)................................................................................ 43
Change of Main Customer ............................................................................................................. 46
Account Closure ............................................................................................................................. 46
Limits .............................................................................................................................................. 51
Account Statements ....................................................................................................................... 51
Account Violations.......................................................................................................................... 53
Payment Netting............................................................................................................................. 55
Standard settlement instructions.................................................................................................... 64
Suppression of unnecessary overrides .......................................................................................... 66
ALT.ACCT.PARAMETER - Alternative Account numbers ............................................................. 67
POSTING.RESTRICT - Posting restrictions .................................................................................. 69
Referral........................................................................................................................................... 70
High Volume Account Performance ............................................................................................... 84
Consolidation of Statement Entires................................................................................................ 91
Consolidation of Category Entries.................................................................................................. 98
Archiving......................................................................................................................................... 99
Statement Print masking ................................................................................................................ 99
US Regulation D Compliance ...................................................................................................... 102
Internal Files................................................................................................................................. 104

TEMENOS T24 User Guide Page 2 of 105

Accounts

Introduction
The Account, Interest and Charges User Guide has been split into several parts to make finding the
relevant information easier.

This part is ‘Account’ and covers the setup and usage of the account application.
Interest and Charges’ which covers the setup and calculation of interest and charges
The following chapters ‘Cheque issue and Management’, ‘Account Sweeping and Multi Level
Cash Pooling‘; ‘GWHT (German With-Holding Tax)’
Please refer to these user guides for further details.

Application Overview
The ACCOUNT module (and its Interest and Charges routines) caters for the creation, maintenance
and control of all types of accounts handled by T24 it also provides:

• Calculation of interest on client accounts.

• Calculation of premium interest on client accounts.
• Calculation of charges relating to the maintenance and servicing of accounts.
• Pre-notification of debit interest and/or charges on client accounts.
• Production of statements, overdraft and referral reports.

Overview of Input and Processing

Accounts can be classified as one of two types, client accounts or internal accounts. Client accounts
are those owned by an external customer such as current accounts, savings accounts etc. Internal
accounts are those owned by us such as suspense accounts.

There are no actual general ledger accounts in T24 to allow for accurate and detailed accounting
analysis, profit and loss balances are not held in an account, instead consolidated balances and
movements are kept at the lowest reporting level by use of specific category codes, which are used by
all applications to record profit and loss entries. The usage of these ‘virtual’ general ledger accounts is
explained in the Reporting chapter of the user guide.

ACCOUNT.PARAMETER

Controls Account & Defaults

The ACCOUNT.PARAMETER record contains high-level specifications for the ACCOUNT

application. For example:

TEMENOS T24 User Guide Page 3 of 105

Accounts

• Number of days forward for cash-flow processing.

• Whether accounting is performed on a value date or booking date basis.
• Whether accounts can be referenced by an alternative id or not.
• Whether the customer number must form part of the account number.
• Whether payments can be netted.
• How settlement defaulting is to take place.

There is only one record, with an ID of SYSTEM.

Figure 1 – ACCOUNT.PARAMETER record

TEMENOS T24 User Guide Page 4 of 105

Accounts

ACCOUNTING
Enforcing balanced accounting entries

In order to maintain the financial integrity of the system, T24 performs a check that the accounting
entries raised by an application balance.

The following applications are an exception to this, in that they can genuinely raise one sided entries;
DATA.CAPTURE (DC) - There is a mechanism to stop unbalanced batches already in place
FIDUCIARY (FD) - Can make 2 separate calls to accounting
REVALUATION.AL - Generates one sided entries during the COB

Set up

In order to use this functionality you will need to input a CATEGORY code to be used specifically for
balancing entries raised by the system

Figure 2 – Example CATEGORY record

A new TRANSACTION code is required.

TEMENOS T24 User Guide Page 5 of 105

Accounts

Figure 3 – Example TRANSACTION record

The Internal account for Local currency will need to be opened for the above CATEGORY code.

Figure 4 – Internal ACCOUNT to be used by the system for balancing entries

The following tables have been released in T24.

TEMENOS T24 User Guide Page 6 of 105

Accounts

Figure 5 – EB.FIN.SYSTEM record

Figure 6 - Example default EB.FINANCIAL.SYSTEM record

The table EB.FINANCIAL.SYSTEM is used to customise the setting that you require. However, our
recommended setting for this in your live environment is as in the above example. If you require
BALANCED.INTRNL to be set to Y then the field INTRNL.BAL.TYPE becomes mandatory and must
contain the id of a record from AC.BALANCE.TYPE which has a REPORTING.TYPE of INTERNAL.

NB For test environments we recommend that the field AUTO.BL.SYS.ONL be set to N as a

minimum. The system will not then raise balancing entries and the user will be unable to
commit the transaction.

Depending on the setting in EB.FINANCIAL.SYSTEM the following will be updated files will be
updated with the details.

TEMENOS T24 User Guide Page 7 of 105

Accounts

Figure 7 – Table showing where error will be reported

Client Account
A client ACCOUNT can be one of many different types, a simple current account, overdraft or savings
accounts and many more. T24’s strength lies in the flexibility within which new account types can be
added to it in order to meet the bank’s ongoing requirements.

T24 is a customer-orientated system. An account is connected to a CUSTOMER record and thus the
owner and address details are not entered on the individual ACCOUNT. This eliminates the need for
extensive maintenance of customer information such as when a customer changes their address.
When T24 is installed, part of the implementation process is to configure the types of accounts the
bank wishes to offer and their characteristics. Typically this would include the debit/credit interest rates,
interest and charges capitalisation frequencies, statement production cycle, other account group
conditions etc. Once these key files are set up the addition of a new client account is very simple.

The processing options available on client accounts include:

• Posting Restrictions
• Referral Conditions
• Alternate Account ids
• Mnemonic codes
• Joint account holders
• Liquidation of interest to another account
• Pre-Notification of debit interest due
• Charges capitalised to another account
• Pre-Notification of charges due
• Interest and Charges settled in currencies other than the account currency
• Combining balances across accounts before interest calculations

TEMENOS T24 User Guide Page 8 of 105

Accounts

• System information fields such as balances etc.

These options are detailed later in this guide.

An example of a simple current account is shown below:

Figure 8 - Client Account

In the above example the account 25976 has a field MNEMONIC that contains a value of LDLEUR.
This mnemonic can be entered into any standard T24 ACCOUNT field and is translated automatically
into the correct ACCOUNT number.
A NOSTRO account is a special type of account, identified by the CATEGORY code and the
LIMIT.REF field containing the word “NOSTRO”. As it is a shadow of the VOSTRO account
maintained by the correspondent, the client id is informational the real account owner is you. An
example of a NOSTRO account is shown below using the following function:

TEMENOS T24 User Guide Page 9 of 105

Accounts

Figure 9 - Nostro Account

When setting up a Nostro Account the client of the ACCOUNT should not receive a statement, or
debit/credit advices. These should be re-directed to your reconciliation’s department. Create a print re-
direct address for the correspondent (e.g. US0010001.C-100002.PRINT.2 on DE.ADDRESS) then in
DE.PRODUCT create a record for the Nostro Account (e.g. US0010001.A-26751.ALL.ALL) this will
prevent any advices for this account being sent to your correspondent.

If SINGLE.LIMIT field in ACCOUNT is set to “Y” then only one account can be attached to a limit
record. If set to “N” then multiple accounts are allowed to utilise a single limit. SINGLE.LIMIT Y/N
can be defaulted from ACCT.GROUP.CONDITION using SINGLE.LIMIT default field.
SINGLE.LIMIT in account can also be used independently without setting up
ACCT.GROUP.CONDITION.

For information on the Reconciliation module, its capabilities and how it can assist your Reconciliation
Department in their daily workflow please refer to the User Guide chapter for that module.

Internal Accounts
Internal accounts are not related to a CUSTOMER record, and are used for maintenance of cash
accounts, accrued profits, suspense accounts, tax and capital accounts. Since there is no
CUSTOMER record related to internal accounts, details such as account title and short title need to
be specified when the account is created.

The account number of an internal account consists of the currency, category and a subdivision
number.
An example of a simple internal cash account is shown below:

TEMENOS T24 User Guide Page 10 of 105

Accounts

Figure 10 - Internal Account

Account Number Format

T24 can use many different Account id structures. These can be any of the ones we supply or new
check digit types can be created on request. To match existing styles you can also apply an Account
mask, which makes it easier for the user to visualise the account’s structure.

Client account number format

The ACCOUNT number on client accounts is a number of up to 16 characters. The format of the
number can be validated if required, for example by the use of check digits or the automatic inclusion
of the CUSTOMER number.

The length and check digit type used for an account is defined in the COMPANY application, in the
fields:

ACCT.CHECKDIG.TYPE
ACC.BKNO.PREFIX
ACCOUNT.MASK
For extended account numbers longer than 16 characters, the input length must be defined in the
EB.OBJECT application, in the field MAX.LENGTH.

TEMENOS T24 User Guide Page 11 of 105

Accounts

ACCT.CHECKDIG.TYPE Please refer to the HELPTEXT on these fields for the settings you require. It
identifies the check digit calculation method for the company being entered.

The following values will be accepted:

'1': When LOCAL.CURRENCY starts with BE (i.e. identifies Belgium).
'2': When LOCAL.CURRENCY starts with LU (i.e. identifies Luxembourg).
'3': For 10 digit account numbers with a modules 11 check.
'4': For 11 digit account numbers constructed with a 2 digit bank number prefix defined in
ACC.BKNO.PREFIX, followed by 7 identifying digits and a 2 digit mod 11 check digit. The prefix may
contain leading zeros.
'5': For a standard check digit calculation with the account numbers zero filled to the ACCOUNT.MASK.
'6': For a 12-14 digit number with 2 check digits, the first 6 digits, and the second on the remaining
digits. The check digits are calculated using mod 11.
'99': No check digit calculation with the account number zero filled to the ACCOUNT.MASK.
'@routine name’: Where a local subroutine performs the check digit calculation.
'blank': in all other cases.

Note: Once a customer account record has been authorised in this company, this field may no longer
be changed.

Validation Rules
The following values will be accepted: '1', '2', '3', '4', '5', '6', '99', @routine name and 'blank'. Mandatory
input when LOCAL.CURRENCY starts with BE or LU.

Internal account number format

The format of an internal account depends on how the environment is set up i.e. single company,
multi-company or multi-book and what the account is to be used for. i.e. cash account, suspense
account, inter-company account, or position accounting . Below we look at the different structures
that can be set up.

Single company

The Internal account number format will be CCYCCCCCNNNN;

• CCY is the Swift currency code of the account e.g. EUR, USD
• CCCCC is a category code in the range 10000 – 19999
• NNNN is a sequential number in the range 0001-9999

TEMENOS T24 User Guide Page 12 of 105

Accounts

Figure 11 - Internal Account ID Structure Single company environment

Position account number format will be CCYCCYCCCCCDDSS;

• The first CCY is the currency code of the account.

• The 2nd CCY is the other currency of the Position relationship.
• CCCCC is a category code in the range 10000 – 19999
• DD is the DEALER.DESK (00 default DEALER.DESK) for which the accounts are being
maintained
• SS is a sequential number which will allow access to sub account processing

Figure 12 – Example of a position ac in a singe company

Multi-company
The Internal and position account numbers remain as above. Due to the nature of the environment
there is the addition of intercompany accounts.

The format of these accounts will be;

• CCY is the Swift currency code of the account e.g. EUR, USD

TEMENOS T24 User Guide Page 13 of 105

Accounts

• CCCCC is a category code in the range 10000 – 19999

• NNNN is the sub division code of the other company in the transaction. Located on the
COMPANY record.

Figure 13 – Example Intercompany account

Figure 14 – Company records showing both sub division codes

In the example above the account is from EU0010001 and the sub division code is 0001 from
company US0010001

TEMENOS T24 User Guide Page 14 of 105

Accounts

Multi-book

However in a Multi-Book environment the simple internal account number format will be
CCYCCCCCNNNNBBBB

• CCY is the Swift currency code of the account e.g. 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 the account belongs to

Figure 15 – Internal account ID structure Multi-book environment

In the above example the sequential number is the till id.

Position account format will be CCYCCYDDSSBBBB;

• The first CCY is the currency code of the account.

• The 2nd CCY is the other currency of the Position relationship.
• CCCCC is a category code in the range 10000 – 19999
• DD is the DEALER.DESK (00 default DEALER.DESK) for which the accounts are being
maintained
• SS is a sequential number which will allow access to sub account processing if required
• BBBB is the sub division code of the company the account belongs to

TEMENOS T24 User Guide Page 15 of 105

Accounts

Figure 16 – Position account in a multi-book area

The intercompany account format will be CCYCCCCCNNNNBBBB

• CCY is the Swift currency code of the account e.g. EUR, USD
• CCCCC is a category code in the range 10000 – 19999 (intercompany category code)
• NNNN is the subdivision code of the other company in the transaction
• BBBB is the sub division code of the company the account belongs to

Figure 17 – Inter company account between lead company and book

Some fixed internal ACCOUNT records are required by T24 applications and must exist prior to
entering any transactions on these applications. These are listed in the ACCOUNT.CLASS records
and are detailed in the field RECORD.TYPE. It is recommended that the local currency account records
be input manually. T24 is able to open any foreign currency account required automatically, providing
that one exists for the specific account category.

The account will have the text ‘RECORD.AUTOMATICALLY.OPENED’ set in fields

ACCOUNT.TITLE.1; ACCOUNT.TITLE.2 and SHORT.TITLE these can then be amended whenever
convenient.

TEMENOS T24 User Guide Page 16 of 105

Accounts

Account Input

Customer Account input

Customer accounts are only opened manually. The account number of a customer account can be up
to 16 numeric characters, subject to local restrictions and requirements; such as check digit validation.

Figure 18 - Client Account

Some details such as the account title, customer who owns the account, CATEGORY and
CURRENCY, are input at this time. However, extensive ranges of characteristics are defined on
related parameters tables. This enables an ACCOUNT to be opened with a minimum of details
required on input and majority of the processing characteristics defaulted from group level parameters.
Consequently, when these characteristics change, perhaps because of a change in business policy,
the modification need only be applied once to the group level parameter, which automatically
processes all the related ACCOUNT records with the new settings.

TEMENOS T24 User Guide Page 17 of 105

Accounts

The types of characteristics that can be set up on the related parameters include:

• Interest rates and methods

• Interest capitalisation frequency
• Statement generation
• Charges
• Posting restrictions.
• Premium Interest rates methods and capitalisation frequency
• Other parameters defining validation rules for transactions over accounts

The majority of these parameters are linked to the account’s CONDITION.GROUP. The
CONDITION.GROUP defines the way the ACCOUNT is processed. It is set automatically by using
characteristics pre-defined by the user. For example the CONDITION.GROUP for a current account for
corporate clients may be different to that for private clients. This might mean that corporate clients
receive statements daily by default whereas private clients receive them monthly.

Generally these characteristics are defaulted by CONDITION.GROUP but they may be overridden for
particular accounts whenever required. For example, the default statement frequency for private
clients in the above example was monthly; however this could be set to weekly for a particular account.

Contingent account

There is sometimes the need to keep balance information for reporting purpose that is below the line
(contingent). To allow for this it is possible to open Contingent Accounts. This facility is available for
both customer and internal accounts.

Therefore it is possible to set up a customer contingent account for guarantees held. Posting to these
accounts can be done through Data Capture and Funds Transfer. This contingent account processing
within T24 is used to calculate interest on a customer unutilised and or utilised amount on a limit.

Customer level contingent accounts are set up to hold the unutilised or utilised limit amount. T24
monitors the limit record and any charges in the unutilised and or utilised amount are posted to the
contingent accounts by way of entries.

For this processing an internal contingent account is used as the other side of each entry. Interest can
be calculated on the customer contingent account.

TEMENOS T24 User Guide Page 18 of 105

Accounts

Set-up of Contingent Accounts

ACCOUNT.PARAMETER
The ACCOUNT.PARAMETER file contains the top-level settings for contingent accounts. It is here
that it is specified which CATEGORY codes can be used for contingent accounts, and also which
TRANSACTION codes should be used for the debiting and crediting of the contingent account, for
limit un-utilisation/utilisation entries.

Figure 19 - ACCOUNT.PARAMETER using contingent accounts

ACCOUNT.CLASS
For unutilised/utilised processing then three ACCOUNT.CLASS RECORDS, namely OFFLIMIT,
UTILLIMIT and OFFSPINT will need to be created. They have to be opened in the

TEMENOS T24 User Guide Page 19 of 105

Accounts

ACCOUNT.CLASS application, with appropriate CATEGORY codes, as mentioned in the

ACCOUNT.PARAMETER table. Internal Accounts are to be opened in the categories mentioned,
to post the contra entries.

Figure 20 - ACCOUNT.CLASS OFFLIMIT

Group Settings for contingent accounts

Contingent accounts, as they have different reporting and accounting consequences than non-
contingent (typical) accounts, have to be set up to have their own groups. As a result, specific
ACCT.GEN.CONDITION, GROUP.CREDIT.INT, GROUP.DEBIT.INT and
GROUP.CAPITALISATION records must be set up to cater for the contingent accounts. These can
be set up in the same way as non-contingent account groups are set up.
The field CONTINGENT.INT which is found in both the ACCT.GROUP.CONDITION and
ACCOUNT records indicates whether the interest calculated on a contingent account is to be treated
as contingent or non-contingent. The field is only populated for contingent accounts. (If the category
of the account is within the range specified in the ACCOUNT.PARAMETER then input is mandatory,
otherwise input is not allowed.)

The presence of a value in this field indicates that the account is a contingent account. The values
permitted for this field are;
“B” to indicate that non-contingent (on balance sheet) interest is to be generated for this
account.
“O” will indicate contingent interest; off balance sheet interest is generated.
“C” will indicate that contingent interest will be calculated only and will therefore not be posted
or appear or any balance sheet.
“I” indicates that the contingent account is internal and therefore no interest is generated
“Null” if this field is not populated then the account is a non-contingent account

TEMENOS T24 User Guide Page 20 of 105

Accounts

Figure 21 – ACCT.GROUP.CONDITION record contingent ac

Figure 22 - ACCOUNT with CONTINGENT.INT populated and possible values

ACCOUNT settings for contingent accounts

When creating contingent ACCOUNT records, if option B is chosen then the fields
INTEREST.LIQU.ACCT and CHARGE.ACCOUNT become mandatory, these accounts must be non-
contingent accounts.

If the ACCT.GROUP.CONDITION record has the CONTINGENT.INT field populated then

accounts that are opened under this group will have the field CONTINGENT.INT populated by default.
The alternative is to set the CONTINGENT.INT field on the account when it is opened.

TEMENOS T24 User Guide Page 21 of 105

Accounts

LIMIT- sweeping of unutilised/utilised amounts: unutilised amounts

The PROCS.LIMIT.SWEEP field on the LIMIT.PARAMETER application must be set to Y to enable

the unutilized/utilised amount on a limit to be swept into a contingent account. There is also a flag on
LIMIT.PARAMETER, ALLOW.UNUTIL.CR, which determines whether, if part of a limit is then
utilised, whether a credit should be passed to the contingent account to reflect this. . There is another
flag on LIMIT.PARAMETER, DEFAULT.MAX.TOTAL, which determines whether, the
INTERNAL.AMOUNT or the ADVISED.AMOUNT of the LIMIT is to be used for the calculation of
unutilised limit amount.

Figure 23 - LIMIT.PARAMETER settings for contingent accounts

LIMIT

The contingent account to which the unutilized/utilised amount of a limit is to be swept is specified in
the LIMIT application, in the UNUTIL.ACCT/UTIL.ACCT fields. It is from here that the current
unutilized/utilised amounts are taken. There is also the option here of overriding the
LIMIT.PARAMETER application on the setting of whether credits to the contingent account should
occur when the unutilised amount is reduced.

TEMENOS T24 User Guide Page 22 of 105

Accounts

Figure 24 - Individual LIMIT settings for contingent accounts

Once set up, the contingent accounts are updated during the end of day. It is also possible to update
the accounts through DATA.CAPTURE and FUNDS.TRANSFER. It is only possible to make a
FUNDS.TRANSFER when both accounts are typical accounts or when both accounts are contingent.
Likewise DATE.CAPTURE the entire batch must be of the same type

NOSTRO Accounts
Nostro account records have a key in the same format as a customer ACCOUNT and the account-
servicing bank is treated as a CUSTOMER for most purposes.

TEMENOS T24 User Guide Page 23 of 105

Accounts

Account balances
The following balances are held on the ACCOUNT record in.

OPEN.ACTUAL.BAL
This field contains the Actual Non-Cleared Balance or 'Ledger Balance' of the Account as at the start
of the day.

OPEN.CLEARED.BAL
This field 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 reversed debit entries with Exposure
Dates in the future.

For credit and reversal debit entries with Exposure Dates in the future, this field is updated in the start
of day processing on the appropriate date.

It is possible to split a single entry amount to clear in separate periods. This feature is called exposure
date splitting. For more information on this feature refer to the following sections in the user guide
(Local Clearing, Application Accounting, System Tables and Teller)

ONLINE.ACTUAL.BAL
This field contains the most up to date Actual Balance of the Account. This is the same as the actual
balance at the start of day (OPEN.ACTUAL.BAL) plus the value of all fully Authorised entries since
the start of day.

ONLINE.CLEARED.BAL
This field contains the most up to date Cleared Balance of the Account. This is the same as the
cleared balance at the start of day (OPEN.CLEARED.BAL) plus the value of all fully authorised entries
since the start of day excepting any credits 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 processing on the appropriate date.

It is possible to split a single entry amount to clear in separate periods. This feature is called exposure
date splitting. For more information on this feature refer to the following sections in the user guide
(Local Clearing, Application Accounting, System Tables and Teller).

TEMENOS T24 User Guide Page 24 of 105

Accounts

WORKING.BALANCE
This field contains the present balance of the Account, which is used for checks done by the LIMITS
system in the start of day this figure will be the same as the cleared balance figure
(ONLINE.CLEARED.BAL).

For Nostros and Internal Accounts the field is updated by all accounting 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 excepting 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 in start of
day processing on the appropriate date.

It is possible to split a single entry amount to clear in separate periods. This feature is called exposure
date splitting. For more information on this feature refer to the following sections in the user guide
(Local Clearing, Application Accounting, System Tables and Teller).

AVAILABLE.BALANCE

Through the Available Funds functionality, T24 will identify if any movements or transactions will
generate a deficit of cash in a client accounts, and will anticipate the impact of a new transaction on
pre-existing client commitments.

DATES
The date updated in the available funds ladder will be selected in the following order of date fields on
the contract resulting in the credit transactions:
1) EXPOSURE.DATE

2) VALUE.DATE if exposure date is blank

3) BOOKING.DATE if value date is blank

While for debit transactions the following order is applied:

1) VALUE.DATE

2) BOOKING.DATE if value date is blank

Exposure Date
The exposure date is the date on which a credit entry is included in the cleared balance of an account.
Value Date
The value date is the date from which the entry is included for calculation of interest. Where there is
no exposure date on the transaction the value date is used as the date which the transaction affects
the available funds.

TEMENOS T24 User Guide Page 25 of 105

Accounts

Booking Date
The booking date is the date on which the transaction has been processed.

Available Funds Window

Available funds balances are held for all forward dated and value dated account movements up to the
number of calendar days forward from today as specified on CASH.FLOW.DAYS in
ACCOUNT.PARAMETER.

EXAMPLE:

If today’s date is 13th of April 2000, and CASH.FLOW.DAYS is set to 10 then:

Window start date will be 13th April 2000

Window end date will be 23rd April 2000

Figure 25 - Account Parameter showing the cash flow window

Any transaction with an exposure date or value date within that period will be included in the available
funds ladder.

Transactions beyond the Window

Any value dated transactions (e.g. Data Capture, Funds Transfer and Teller) with exposure date or
value date beyond the window will cause the window to expand for that account.

As a consequence of this, any forward dated transactions (e.g. Money Market, Loans) with a value
date beyond the window will automatically be included in the available funds ladder.

Backdated transactions

TEMENOS T24 User Guide Page 26 of 105

Accounts

Any transactions with a value date or exposure date less or equal to today’s date will be held under
today’s date available funds ladder.

Example of a backdated transaction and a transaction beyond the window on the following account:

Here is the account before a back-valued transaction is entered:

Figure 26 - Existing account before back-valued transaction entered

We then enter (and authorise) a back-valued funds transfer, which has the effect of debiting this
account:

TEMENOS T24 User Guide Page 27 of 105

Accounts

Figure 27 - Enter funds transfer to debit account

The account now shows a debit movement and balance in the available funds fields, with the value
date of today:

TEMENOS T24 User Guide Page 28 of 105

Accounts

Figure 28 - Account after debit payment has been passed

MOVEMENTS
Available funds will hold unauthorised and authorised transactions separately, so while
WORKING.BALANCE ignores unauthorised credits and future authorised credits, AVAILABLE.BAL
may contain either unauthorised credits or unauthorised debits or both of them or even neither of them.

All the movements will be held as follows unless a restriction has been set in EB.AF.PARAM at
transaction or application level:

TEMENOS T24 User Guide Page 29 of 105

Accounts

AV.AUTH.DB.MVMT - authorised debits

AV.NAU.DB.MVMT - unauthorised debit movements
AV.AUTH.CR.MVMT - authorised credits
AV.NAU.CR.MVMT - unauthorised credits

More details on EB.AF.PARAM are described below.

BALANCES

Open Available Balance

The available balances are built using the OPEN.AVAILABLE.BAL as the starting balance. At the
start of day the OPEN.AVAILABLE.BAL consists of all authorised debits with value date less or equal
today plus all authorised credits with an exposure date less or equal today (excluding contract entries,
such as the principal draw down of a loan valued today).

Available Balance
The AVAILABLE.BAL always includes authorised debits and credits. The parameterisation regarding
the update of available balances with unauthorised entries takes place as follows via
AVAILABLE.BAL.UPD:

ACCOUNT.PARAMETER

BOTH - Unauthorised debits and credits to make up available balance

NONE - No unauthorised movements to update available balance
DEBITS - Only unauthorised debits to make up available balance
CREDITS - Only unauthorised credits to make up available balance

This option is also available at ACCT.GROUP.CONDITION and ACCOUNT level.

Note: If unauthorised debits/credits are excluded from the AVAILABLE.BAL, the movements will still
be updated unless they have been blocked in EB.AF.PARAM.

Credit Checking
A credit check is made whenever a debit transaction is validated or is validated and authorised at the
same time.

An option is available to set credit checking for an account against working balance and cash flows or
available balance via the CREDIT.CHECK field in ACCOUNT.PARAMETER, the options are as
follows:

TEMENOS T24 User Guide Page 30 of 105

Accounts

• Null or WORKING - The update of available funds ignores unauthorised credits.

- Overdraft checks use only working balance.
- Future cash flow check uses the Available balance ladder as from the
value/exposure date of the transaction
• FORWARD - Same as above, except that overdraft use WORKING.BAL +
FORWARD.MVMTS for today
• AVAILABLE - The update of Available funds uses the AVAILABLE.BAL.UPD to
decide how the available balance is to be updated
- There is no overdraft check.
- Future cash flow check uses available balance ladder as from the
value/exposure date
• AVAILWRK - The update of the Available funds uses AVAILABLE.BAL.UPD
- The overdraft check uses WORKING.BALANCE only
- Future cash flow checks uses Available balance ladder as from the
value/exposure date.
• AVAILFWD - The update of Available funds uses AVAILABLE.BAL.UPD
- The overdraft check uses WORKING.BAL + FORWARD.MVMTS
- Future cash flow check uses Available balance ladder as from the
value/exposure date.
This field may be left blank; in this case, the ‘Working’ option applies.

This option is also available in the ACCT.GROUP.CONDITION and ACCOUNT application in the
following order:

• ACCOUNT – a flag set here always takes precedence over a flag set elsewhere.
• ACCT.GROUP.CONDITION (If ACCOUNT is blank).
• ACCOUNT.PARAMETER (If all of the above applications have not been set).

If set to AVAILABLE then all credit checks will be made against the Available Balances and Working
Balance will be ignored although the Available funds movements are still populated to the account.

If an account is linked to a limit then a limit check will take place, otherwise an available balance check
will take place.

If an account is linked to a Shared Balance then the system will still take the available balance and the
shared balances are not included.
The AVAILABLE.BAL used for credit checking will be made up of the movements as defined by
AVAILABLE.BAL.UPD.

TEMENOS T24 User Guide Page 31 of 105

Accounts

Override Messages

Available Balance Excess

An Available Balance Excess override message will be raised if an account is linked to a limit and an
on-line debit transaction has caused the overdrawn available balance on value date of the transaction
to exceed its Limit.

Available Balance Overdraft

An ‘AVAILABLE.BALANCE.OVERDRAFT’ override message will be raised if an account is neither
linked to a Limit nor to a Shared Balance pool and if an on-line debit transaction will cause the
available balance to negative as of the value date of the transaction.

Available Balance Limit Excess

An ‘AVAILABLE BALANCE LIMIT EXCESS’ override message will be raised if an account is linked to
a limit and the available balances of all the accounts in LIMIT falls below the limit amount.

Available Balance Limit Expired

An ‘AVAILABLE BALANCE LIMIT EXPIRED’ override message will be raised if an account is linked to
a limit and the transaction falls beyond the expiry date of the limit.

Available Balance below Locked Amount

An ‘AVAILABLE BALANCE BELOW LOCKED AMOUNT’ override message will be raised if an
account’s balance that has an AC.LOCKED.EVENT record falls below the level of the locked
amount.

Parameters
EB.AF.PARAM
This application defines the blocking parameters of unauthorised transactions to the available funds
movements. The blocking may be set at application level or at transaction level within an application.

The application has to be a valid record id in EB.SYSTEM.ID.

A blocking at transaction level within an application will take priority over whatever is set for that
application level.

In the function below, blocking parameters have been set for all unauthorised credits and debits within
DC (DATA.CAPTURE).

TEMENOS T24 User Guide Page 32 of 105

Accounts

Figure 29 - EB.AF.PARAM showing the available funds parameter set for Data Capture

If an unauthorised transaction is blocked, then neither the movements nor the available balance will be
updated and also no credit check is made for that transaction.

The parameters present in this application are the ones that will be used for blocking unauthorised
transactions for available funds processing. Any change to these parameters must be made through
EB.AF.PARAM.CHANGE.

EB.AF.PARAM.CHANGE
This application allows the input of blocking parameters for available funds processing for an
application.

Fields AVAIL.BAL.NAU.DR and AVAIL.BAL.NAU.CR are used to define the blocking for the
application.

In the example below, blocking parameters have been set for DC

TEMENOS T24 User Guide Page 33 of 105

Accounts

Figure 30 - Available Funds Parameter Change for Data Capture

From the example

Application
The first two fields define the blocking parameters for the application

• Having the field AVAIL.BAL.NAU.DR set to blank means that all unauthorised debits for DC
should update the available funds movements and the available balances and also credit check
should be made.
• Having the field AVAIL.BAL.NAU.CR set to ‘NO’ means that none of the unauthorised credits
for DC should update either available funds movements or available balances.

Transaction
If a blocking parameter that is different from what has been set for the application needs to apply for a
transaction code, then these parameters need to be set under the transaction code.

In the above example, any DATA.CAPTURE entered which uses transaction code 1 (Miscellaneous
Debits) will be blocked from updating any unauthorised debits.

All other transaction codes used in DATA.CAPTURE will take the blocking parameters set for the
application.

TEMENOS T24 User Guide Page 34 of 105

Accounts

If the field AVAIL.NAU.DR were set to ‘NO’ then no un-authorised miscellaneous debits in
DATA.CAPTURE would update the available funds movements and the available balances. As a
result, no credit checking would be made for that unauthorised transaction.

Effective Date
The Effective Date field defines the date at which the parameters take effect, by default it will take
today’s unless the date a future date is input.

Once the parameters have been set in EB.AF.PARAM.CHANGE, depending on the effective date,
they will be written to the EB.AF.PARAM during the Close of Business.

ACCOUNT, ACCT.GROUP.CONDITION and ACCOUNT.PARAMETER

Five parameters may be set at ACCOUNT level or ACCT.GROUP.CONDITION or

ACCOUNT.PARAMETER for the available funds processing:

CREDIT.CHECK
This field defines on what balance credit check is to be made, the possible values are:
• WORKING or NULL (blank)
• FORWARD
• AVAILABLE
• AVAILWRK
• AVAILFWD

TEMENOS T24 User Guide Page 35 of 105

Accounts

Figure 31 - Credit Check set to Account Level

AVAILABLE.BAL.UPD

This field defines which unauthorised movements are included in the AVAILABLE.BAL field that will
be used for credit checking:

BOTH Indicate that both unauthorised debits and credits are included in the Available
Balance.
NONE Indicates that no unauthorised debits or credits are included in the Available Balance.

TEMENOS T24 User Guide Page 36 of 105

Accounts

DEBITS Indicate that only unauthorised debits are included in the Available Balance.
CREDITS Indicate that only unauthorised credits are included in the Available Balance.

Figure 32 – AVAILABLE.BAL.UPD set at Account Level

The following order will apply:

ACCOUNT

TEMENOS T24 User Guide Page 37 of 105

Accounts

ACCT.GROUP.CONDITION
ACCOUNT.PARAMETER

Rebuilding Available Funds

In order to use the available funds functionality, the available funds ladder must be built for accounts
with existing future transactions, otherwise only new transactions will be reflected in the available
funds.

The application AF.REBUILD.REQUEST allows the rebuild to be done at 3 different levels

• Individual accounts
• Account group level
• All accounts

Figure 33 - AF.REBUILD.REQUEST for account 19027

The rebuild will then take place during the COB, in the BATCH
SOD.AVAILABLE.FUNDS

TEMENOS T24 User Guide Page 38 of 105

Accounts

Figure 34 - BATCH ENTRY showing the jobs under SOD.AVAILABLE.FUNDS

The AF.REBUILD.REQUEST can also be used to rebuild the available funds ladder if any data
corruption is suspected.

Available Funds and Shares Balances

If an account is a member of a shared balances group then an exposure-dated ladder will be
constructed using the combined balances of all the accounts in the group. The combined exposure
dated ladder will consist of a combination of all the available balances for every account associated
with that group. When an online debit transaction takes place then the ladder will be updated with the
transaction amount for the appropriate date. The system will then check to make sure that there is an
overdraft. If so, then an override message will be generated.

Set up Cash Pooling for Available Funds

The first part is to set-up the AC.CP.GROUP.PARAM file with some sort of cash pooling id. The
MAIN.MASTER field must consist of the main account number for the cash-pooling group.

TEMENOS T24 User Guide Page 39 of 105

Accounts

Figure 35 - AC.CP.GROUP.PARAM record

Once the AC.CP.GROUP.PARAM record has been set-up, the next phase would be to set-up the
AC.CASH.POOL record. The id must be the main master account number and all the accounts
linked to the particular group must be set-up under the LINK.ACCT field.
When fields such as BACK.VALUE.ADJ BACK.VALUE.CAP BALANCE.TO.USE & SUB.GROUP are
amended any underlying records relating to that AC.CP.GROUP.PARAM will have the field
LAST.MAINT.DATE on AC.CASH.POOL UPDATED to today’s date. This is because the terms of
the sweep have been altered and back valued adjustments would not follow the same rules as were
previously in place before the changes.

Figure 36 - AC.CASH.POOL record

TEMENOS T24 User Guide Page 40 of 105

Accounts

Once the two cash pooling files have been set-up with the group ids, the SB.GROUP.ID field for all
the accounts linked to that particular group will be updated with the cash-pooling id. Please note, if you
are doing an overdraft check on the combined balances of available funds then please make sure that
the CREDIT.CHECK field of the account has been set to AVAILABLE.

Figure 37 - Account record with SB.GROUP.ID filed

When a transaction of some sort is passed through to an account that is linked to a cash pool, the
system will then get all the available balances of all the accounts linked to that same cash pool and
combine them to create an available funds exposure dated ladder. Once the ladder has been created,
the system will locate the date of the transaction on the ladder and then sift through all the combined
balances, displaying the highest overdraft as an override. Below is an example of an overdraft for a
group of combined available fund balances.

Date ACCOUNT A ACCOUNT |B ACCOUNT C

Opening Bal -1000.00 0.00 1000.00
03/03/02 -2000.00 1000.00 3000.00
04/03/02 -2000.00 -2000.00 -2000.00
05/03/02 1000.00 -3000.00 -2000.00
06/03/02 1500.00 -3000.00 1000.00
07/03/02 1500.00 -3000.00 -4000.00
08/03/02 1000.00 -3000.00 -3000.00
09/03/02 -3000.00 -3000.00 -3000.00
10/03/02 -3000.00 5000.00 -3000.00

TEMENOS T24 User Guide Page 41 of 105

Accounts

11/03/02 -3000.00 5000.00 -1000.00

12/03/02 -3000.00 7000.00 0.00

A Funds Transfer transaction is then passed to ACCOUNT a value dated 07/03/02 for 10,000.00
debits.

Date ACCOUNT A ACCOUNT B ACCOUNT C

Opening Bal -1000.00 0.00 1000.00
03/03/02 -2000.00 1000.00 3000.00
04/03/02 -2000.00 -2000.00 3000.00
05/03/02 1000.00 -3000.00 3000.00
06/03/02 1500.00 -3000.00 1000.00
07/03/02 -8500.00 -3000.00 -4000.00
08/03/02 -9000.00 -3000.00 -3000.00
09/03/02 -13000.00 -3000.00 -3000.00
10/03/02 -13000.00 5000.00 -3000.00
11/03/02 -13000.00 5000.00 -1000.00
12/03/02 -13000.00 7000.00 0.00

Table of balances after 10000 FT debit to ACCOUNT A

Nb The balances displayed in red in the tables above are for information only. Note that these will not
actually appear in the account records. They will only appear is a balance has changed.

Once the transaction is processed the available balances for ACCOUNT A, ACCOUNT B and
ACCOUNT C will be combined to create an available funds date exposure ladder as seen below.

DATE COMBINED

Opening balance 0.00

03/03/04 2000.00
04/03/02 -1000.00
05/03/02 1000.00
06/03/02 -500.00
07/03/02 -15500.00
08/03/02 -15000.00
09/03/02 -19000.00

TEMENOS T24 User Guide Page 42 of 105

Accounts

10/03/02 -11000.00
11/03/02 -9000.00
12/03/02 -6000.00

Table showing combined balances for ACCOUNT A, B and C.

When the date exposure table has been created, the system will then look at all the combined
available balances from the 07/03/02 onwards and find the highest overdraft amount. In this example
the highest overdraft amount is on the 09/03/02, so therefore an overdraft message will be displayed
for the user, showing the date, group id, account number and the amount of –19000.00.

Locking of Funds (Blocked or Held Amounts)

T24 has the functionality to lock funds on an Account (also known as blocked or held amounts).
Defined amounts can be locked for specified periods of time, with an override being required where a
transaction takes an Account below the value of the locked funds.

The locked amount was previously input directly to the Account record but now each locked amount is
input as a separate event.

This is achieved through use of the application AC.LOCKED.EVENTS. This application must be
populated with the required details as follows:

ACCOUNT.NUMBER – The Account Number that will have the locked amount.
FROM.DATE – The date the locked amount will commence.
TO.DATE – The final date the locked amount will be held. Funds will be release as from
the start of the following day. If the field is left blank, then the locked event will
stay forever in the account until the event is manually reversed.
LOCKED.AMOUNT – The amount of funds to be reserved for the above period.

TEMENOS T24 User Guide Page 43 of 105

Accounts

Figure 38 - AC.LOCKED.EVENTS INPUT

The ACCOUNT application shows a ladder of locking events applied to that account, and will
automatically include a locked event of zero amounts starting from the date following the last TO.DATE
in any AC.LOCKED.EVENTS record applicable to that account.

Figure 39 - Account after authorised locked event

Note: Since the TO.DATE field was left blank, then no zero locked amount item is added to the
ladder to show the maturity of the event.

TEMENOS T24 User Guide Page 44 of 105

Accounts

If there is an existing locking event applied to an account, then any new AC.LOCKED.EVENTS
record that covers all or part of the same period will result in the locked amount for the common dates
in the ladder being the sum of the LOCKED.AMOUNT fields for those periods.

Credit Checking
When an AC.LOCKED.EVENT record is raised for an account, if the current balances is already
below the locked amount the credit check will be done and an override message will be displayed to
the user.

Exact functionality of this feature will depend on whether credit checking is being undertaken based on
the setting in the CREDIT.CHECK field.

Current overdraft check

If the CREDIT.CHECK field is set to NULL, WORKING, AVAILFWD, AVAILWRK or FORWARD then
the system will use the worst-case scenario. The working balance or working plus today’s forward
movements will be checked against the highest amount in the locking ladder only and an override
generated as applicable.

Future overdraft check

Single Accounts
The system will check all of the available balances within the available funds ladder against the locked
events ladder and override messages generated accordingly.

Group Accounts
If an account forms part of a Cash pool, then an aggregated locked amount ladder is built in and the
group aggregated available balance ladder is checked against the group aggregated locked amount
ladder.

It should be noted that the override ONLY displays that the account will fall below the
LOCKED.AMOUNT and not the actual amount by which the account is short.

Matured Locked Events

On the start of day following the TO.DATE of the locked event, the matured locked event will be
written to history and deleted.

Hence the Account record will be updated accordingly and will no longer hold that locked amount.

Conversion of Existing Accounts

TEMENOS T24 User Guide Page 45 of 105

Accounts

The accounts with existing locked amounts will be converted such that each existing locked amount
will be mapped to a locked event.

If a locked amount was set without any start date, the conversion date is used and no maturity is set to
locked event. Thus the locked amount will be held permanently in the account unless the event is
manually deleted or changed.

Change of Main Customer

It may be required that the customer in an ACCOUNT record needs to be modified with that of another
customer, in cases like death of the main customer in an ACCOUNT record with JOINT.HOLDER.
T24 allows modification of the main CUSTOMER.ID for an ACCOUNT record with JOINT.HOLDER
to any one of the existing JOINT.HOLDER in the ACCOUNT record does not allow modification of
the main customer if there are limits linked to the customer.

Modification of the main customer is validated against the CATEGORY range as defined in
ACCOUNT.PARAMETER application under the record SYSTEM. The following screen shot shows the
example set-up of CATEGORY range in ACCOUNT.PARAMETER.

Figure 40 - ACCOUNT.PARAMETER

Modification of the main CUSTOMER.ID for an ACCOUNT record with a single holder is allowed only
for NOSTRO type of accounts, even if the NOSTRO CATEGORY range is specified in the
ACCOUNT.PARAMETER application.

Account Closure
It is possible to close an account both Online and during the Close of Business.

The application ACCOUNT.CLOSURE is used to close accounts whether online or during the close of
business. The account number is used as the record id, and the system will calculate outstanding
interest, premium interest and charges. You may amend the capitalisation date, settlement account
and the posting restriction to be placed on the account record

TEMENOS T24 User Guide Page 46 of 105

Accounts

The example screen below shows the ACCOUNT.CLOSURE record where the account will be closed
during the Close of Business:

Figure 41 – ACCOUNT.CLOSURE

Interest and Charges are calculated on the value dated balances and account activity statistics stored
in the ACCT.ACTIVITY file, taking into account all entries over the account up to and including the last
end of day processing.

When an account is flagged for closure, any entries over the account require an override.

During end of day processing the following working day, if the OPEN.ACTUAL.BAL and
OPEN.CLEARED.BAL are both zero, the account is closed.

If it is required to close the account online then the field CLOSE.ONLINE should be set to Y. In
addition to this the user must decide which application will be used to pass the entries, which will settle
the account. FUNDS.TRANSFER, TELLER or ACCOUNT.CLOSURE can be used to pass these
entries. The field CLOSE.MODE will accept FT, TELLER or NULL, if NULL is specified then
ACCOUNT.CLOSURE will be used. Once the ACCOUNT.CLOSURE record is authorised the system
will raise the relevant entries and move the account record to history.
If FUNDS.TRANSFER is used after the ACCOUNT.CLOSURE record is input the system will
automatically raise an FT record and place it on hold, the id of the FT is stored in the field FT.ID.
Once the FT has been authorised, and the OPEN.ACTUAL.BAL and OPEN.CLEARED.BAL are both

TEMENOS T24 User Guide Page 47 of 105

Accounts

zero, the ACCOUNT.CLOSURE record should be authorised and the account is closed and moved to
history.
If Teller is specified in the ACCOUNT.CLOSURE record, the system raises a TELLER.DEFAULT
record the ID of record is the ACCOUNT number, this record holds information that will be used in the
TELLER transaction which will pass the entries. The user is required to input a TELLER record, the ID
of the TELLER.DEFAULT record should be populated in the OUR.REFERENCE field of the TELLER,
(once the TELLER.DEFAULT record has been processed it can not be reused), and this will then
populate the transaction with details from the ACCOUNT.CLOSURE. Once the TELLER is authorised
and the OPEN.ACTUAL.BAL and OPEN.CLEARED.BAL are both zero, the ACCOUNT.CLOSURE
record should be authorised, and the account will closed and move to history.

Below is an example where Teller is being used to close an account online.

Figure 42 - ACCOUNT.CLOSURE – with ONLINE set to Y and closure Mode is Teller

TEMENOS T24 User Guide Page 48 of 105

Accounts

Figure 43 - TELLER.DEFAULT record created by ACCOUNT.CLOSURE

TEMENOS T24 User Guide Page 49 of 105

Accounts

Figure 44 - An example TELLER – used to pass settlement entries

The system will not allow an account to be closed if it meets one of the following criteria
• Part of a SAM
• Direct Debit
• If it is a liquidation account

TEMENOS T24 User Guide Page 50 of 105

Accounts

• Interest compensation account

• Charge account
• All-In-One account
• Part of a sweep account
• Part of a cash pool
• Not in current company
• Part of collateral
• Unauthorised AC.PENDING exists
• Blocked using AC.BLOCK.CLOSURE
• Closure should not be flagged when account is in suspense

Limits
The LIMIT.REFERENCE field on the ACCOUNT connects the account with the LIMIT system. Limits
are checked at each on-line transaction and at end of day. The value in this field will automatically be
set to NOSTRO for that type of account or a valid LIMIT.REFERENCE relating to a product or global
limit.

For certain types of limit product it is possible to net credit account balances and debit account
balances (the usual practice is to only include debit balances for limit checking). If an account with a
credit balance is to be included in the limit checking, the field ALLOW.NETTING should be set to YES.

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 can be produced every working day, for 1-9 weeks, twice a month (on the 15th and the last
day of the month) or for 1-99 months (using any day of the month as the anniversary or on the month
end date).

Two statement cycles may be specified for each account, e.g. weekly and monthly.

These cycles may be independent or combined:

• Separate: 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.

TEMENOS T24 User Guide Page 51 of 105

Accounts

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.

When a duplicate / interim statement is produced on request a charge may be applied for the issue of
the statement.

This charge is usually deferred until the next time the statement is printed in accordance with the
statement frequency. The charge may now be made immediately, together with the production of a
debit advice detailing the charge made when the duplicate statement is produced.
The field PRINT.ROUTINE on the PRINT.STATEMENT file can be used to specify the name of an
external routine written by the users that will be called to print the statement. If this field is populated
the program will call this routine and ignore the normal printing process.

Another field CHARGE.ROUTINE on the PRINT.STATEMENT file could used to specify the name of
an external routine written by the users that will be called to apply an immediate charge to the account
for which the statement is being reprinted.

The alternative method of raising the charge accounting entries would be to use the Generic
Accounting Interface.

Figure 45 - PRINT.STATEMENT

TEMENOS T24 User Guide Page 52 of 105

Accounts

Account Violations
The AC.VIOLATION file is used to record and report violations that occur on an account within a
statement period. All transactions eligible (i.e. defined in ACCT.GROUP.CONDITION) are recorded in
this file whether or not the number of transactions equals the threshold concerned. If the number of
eligible transactions equals or exceeds the TXN.THRESHOLD for the ACCT.GROUP.CONDITION,
the AC.VIOLATION record is flagged as being in violation (i.e. VIOLATION.STATUS = Y). This file
is updated daily during the End-of-Day processing but may be also be updated manually if a
transaction needs to be added or a status changed. Transactions are held by STMT.ENTRY id.
Records remain on the AC.VIOLATION file for the length of time defined in the
RETENTION.PERIOD field on the relevant ACCT.GROUP.CONDITION.
Account violations occurring prior to the completion of a statement period will be generated in the
Close of Business processing and held on the AC.VIOLATION file with an id composed of the
account number alone.

Figure 46 – ACCT.GROUP.CONDITION record

TEMENOS T24 User Guide Page 53 of 105

Accounts

Figure 47 – ACCOUNT which has broken the rules set in the ACCT.GROUP.CONDITION

Figure 48 – AC.VIOLATION record for the above account

TEMENOS T24 User Guide Page 54 of 105

Accounts

On completion of the statement period, all entries on the AC.VIOLATION file held with an id of the
account number, will be amalgamated into the violation record for the statement period just passed. i.e.
that held on the AC.VIOLATION file with an id composed of both the account number and the
statement period having just passed.

Payment Netting

The payment netting facility provides the ability to automatically net payments with a counter party in
the same currency and with the same value date. Netting is permitted only when a
NETTING.AGREEMENT is held with the counterparty. The netting agreement has a finite life and
indicates which currencies may be netted with this counterparty.

Net payments must be agreed and approved before the payment is generated. This is done using the
NETTING application. T24 will automatically consolidate payments eligible for netting into a ‘netting
group’, which will appear as a single record on the NETTING application. This record may then be
reviewed and confirmed with the counter party. Authorisation of the NETTING record will generate
the single netted payment.

During the review of the NETTING record, individual payments may be rejected for inclusion in this
net payment. Any payments thus rejected will remain in suspense and will automatically be included in
the next netting group created for the same currency, customer and value date. Once a payment has
been selected for netting it can only be made using the NETTING application.

Netting groups may be created during theT24 overnight processing (based upon forward deals) or on-
line (using the CREATE.NETTING application) for spot deals.

The accounting entries for payments that are to be passed across a suspense account, which should
have a zero balance once all net payments have been sent.

Individual payments that are to be net are recorded on the NETTING.ENTRY application. This is a
‘live’ file; i.e. it is not available for input. There is one NETTING.ENTRY record for each contract.

TEMENOS T24 User Guide Page 55 of 105

Accounts

Figure 49 - Netting file structure

Accounting for net payments

Payments that are netted pass across a suspense account. For example if we are paying US dollars
to a counterparty with a value date of spot, and are expecting one receipt of US dollars funds from the
same counter party with the same value date then if we are not netting payments, T24 will generate
the following entries:

Figure 50 - Standard accounting entries

If the payments were netted then T24 would generate the following:

Figure 51 - Accounting entries with payment netting

TEMENOS T24 User Guide Page 56 of 105

Accounts

All entries in the above examples are STMT.ENTRY records.

Installing the payment netting function

The following steps need to be followed:

1. Open new TRANSACTION codes for netting entries.

2. Open a new CATEGORY code for netting suspense accounts.
3. Open an ACCOUNT.CLASS record for NETTING.
4. Open the netting suspense accounts (only one is mandatory).
5. Input the NETTING.PARAMETERS record.
6. Set the ACCOUNT.PARAMETER to allow netting.

Setting up the payment netting suspense accounts

The payment netting facility requires suspense accounts. Setting up these accounts is done in two
stages: an ACCOUNT.CLASS record is created and then a suspense account is opened which will
act as a template for all the suspense accounts.

The ACCOUNT.CLASS record to be established has a key of NETTING. This record is used by T24
to determine the characteristics of the suspense accounts to be set up to hold the netted payments.
Before setting up the record a new CATEGORY code should be created for netting suspense
accounts. This code will be referenced by the ACCOUNT.CLASS parameter.

Figure 52 - Netting ACCOUNT.CLASS record

TEMENOS T24 User Guide Page 57 of 105

Accounts

Once this is complete the internal netting suspense accounts may be opened using the ACCOUNT
application. The id of these accounts is the same as any other internal account, i.e. the CURRENCY,
CATEGORY, and a four-digit identifier. EG USD149550001.

Figure 53 - Netting Suspense Account

The ACCOUNT.PARAMETER contains a field (NETT.PAYMENTS), which must be set to YES for
payment netting to take place.

Figure 54 – ACCOUNT.PARAMETER set for netting

TEMENOS T24 User Guide Page 58 of 105

Accounts

NETTING.PARAMETERS
The NETTING.PARAMETERS application controls the payment netting facility. Only one record
may exist (with the id of the system). It specifies the TRANSACTION codes to be used for netting
payments, the number of days prior to the payment value date that netting records should be created,
and the period that history should be kept before netting information is purged from the system.

Figure 55 - NETTING.PARAMETERS

Use of the NETTING.STATUS field on contracts

All contracts whose payments may be netted contain a field called NETTING.STATUS. This field may
be used at contract input time to stop the payments arising from this contract being netted.

NETTING.AGREEMENT

The NETTING.AGREEMENT application contains agreements with counterparties to net payments

of the same currency and value date. One agreement can be made with each counterparty
(CUSTOMER) and the agreement may specify that only payments of particular currencies may be
netted and only payments arising from particular T24 applications may be netted.

The agreement lasts for a finite period as specified in the start and end date fields. The agreement
may be input and amended at any time.

TEMENOS T24 User Guide Page 59 of 105

Accounts

Figure 56 - Example of NETTING.AGREEMENT

CREATE.NETTING

This application is used to create netted payments on-line. Verification of a CREATE.NETTING

record will activate the payment netting process. This will combine all outstanding payments that
match the specified criteria into NETTING records. These can then be reviewed, amended if
necessary, and authorised thus creating the net payments.

Payments can be netted for any combination of counter-party, currency and value date. Thus a record
can net all outstanding payments for a single counter-party, only those for a single currency for that
counter-party etc. The specification of counterparty is mandatory.

Figure 57 – Example of a CREATE.NETTING record

The NETTING.ENTRY application

The NETTING.ENTRY application contains details of all entries being netted. Records are created
here upon authorisation of the original contract. When an individual payment has been successfully
included in a net payment then its entry on this file is updated. The id of the records is the original
contract id. The record contains details of each payment arising from the contract where the payment
is being netted.

TEMENOS T24 User Guide Page 60 of 105

Accounts

Figure 58 – Example of a NETTING.ENTRY

Figure 59 – Additional NETTING.ENTRY

TEMENOS T24 User Guide Page 61 of 105

Accounts

The NETTING.ENTRY record also holds details of the status of each individual payment. Each
individual payment can have one of two statuses -statuses; ‘waiting to be included in a net payment’
and ‘included in a net payment’. The status is recorded in the field NP.REF. If this field does not
contain a value then the individual payment is waiting to be netted. Once the individual payment has
been included in a net payment then this field will be updated with the reference of the NETTING
record.

The NETTING application

The NETTING application is the main control over the net payments process. All individual payments
selected for netting are combined into a single netting record for the counterparty, currency, and value
date combination. This record may then be reviewed and amended if necessary. Once the net
payment is correct the netting record is authorised and T24 will create the single net payment or
receipt accounting and delivery messages.

Individual payments may be dropped from a net payment at this point. If dropped they will remain in
suspense until captured in another net payment. Therefore once a payment has been selected for
netting, it can only be paid using the NETTING application. Individual payments may, of course, be
removed from netting by reversing and re-inputting the source contract and ensuring that the
NETTING.STATUS field is set to NO on the re-input.

T24 creates NETTING records automatically during the overnight batch run or on-line using
CREATE.NETTING. These records are created with a status of ‘hold’ ready for review and possible
input. Once a NETTING record has been confirmed as being valid; (possibly following confirmation
with the counterparty), it should be authorised. T24 will then generate the single net payment.

TEMENOS T24 User Guide Page 62 of 105

Accounts

Figure 60 – NETTING record using the previous NETTING.ENTRIES

TEMENOS T24 User Guide Page 63 of 105

Accounts

Figure 61 – Authorised NETTING record

Settlement details, such as bank to bank-to-bank information, may be added to the NETTING record
and will be used on the resultant net payment. Additionally individual payments may be removed from
the netting record if necessary by using the NETTING field. Payments removed from the record will
remain in suspense until another netting record is generated (either in the T24 batch or by the
CREATE.NETTING application).

Standard settlement instructions

The field SYS.CODE in ACCOUNT.PARAMETER holds the combination of application-activity or

“ALL” based on which the settlement accounts such as Drawdown, Liquidation etc are defaulted in
Applications such as LD, MM etc. In the application AC.SYS.CODES, the above application-activity
combinations can be defined along with the relevant description. The required SYS.CODE in
ACCOUNT.PARAMETER can be selected through the linked application AC.SYS.CODES and
enrichment as given in AC.SYS.CODES will appear here.

TEMENOS T24 User Guide Page 64 of 105

Accounts

Example LD-INT, which refers to the interest liquidation account in the LD application, can have a
record in AC.SYS.CODES as follows:

Figure 62- AC.SYS.CODES with description

CUSTOMER.SSI is an application which is used to define the Standard settlement instruction (SSI)
for a particular customer which is then used to default settlement account fields such as DRAWDOWN
ACCOUNT, PRINCIPAL LIQUIDATION ACCOUNT & INTEREST LIQUIDATION ACCOUNT,
in applications such as LD, MM, FX, MG, NETTING, BL.BILL, PD.CAPTURE &
PRE.SYNDICATION.FILE. The field CUSTOMER.SSI in the ACCOUNT.PARAMETER is used
to control the above feature.

Figure 63- CUSTOMER.SSI field in ACCOUNT.PARAMETER

If this field is set to “YES” (along with DEFAULT.ORDER field of the required SYS-CODE field as
blank) then during input of contracts for the above applications, the system first checks for a matching
record (combination of CUSTOMER, CURRENCY, SYSCODE or “ALL”) in CUSTOMER.SSI to
default in the relevant settlement Account fields. During capture of a contract the SSI’s defined have
the highest priority for defaulting.
In case the Counter party does not have a record for the above combination in CUSTOMER.SSI,
then overrides are generated at the application level and the settlement accounts are defaulted as per
existing functionality of the respective application.
In case the CUSTOMER.SSI field in ACCOUNT.PARAMETER is set as ‘blank’, then the system
will not allow input in CUSTOMER.SSI application and uses the existing functionality of the
respective application for defaulting settlement accounts.

Example:
Create the following record in CUSTOMER.SSI application for customer no. 1044 (Michael Dell):

TEMENOS T24 User Guide Page 65 of 105

Accounts

Figure 64 - CUSTOMER.SSI Set-up for a Customer

While inputting a LD contract in USD for the above customer, the settlement accounts get defaulted as
shown below using above set-up:

Figure 65 - Defaulted settlement accounts in LD

Suppression of unnecessary overrides

If a single contract will create 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.

TEMENOS T24 User Guide Page 66 of 105

Accounts

For example, if a discounted loan is arranged for a client, 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 would usually generate an override specifying that as the customer is being debited $100,
the client is overdrawn by $90. However, it is possible through the fields NET.OD.APPL,
NET.OD.OVERRIDE on ACCOUNT.PARAMETER to net off the differences so as the credit of
$1000 exceeds the debit of $100, the override can be suppressed.
The applications for which this functionality is needed is entered into the NET.OD.APPL field and it
can be switched on or off by setting NET.OD.OVERRIDE as ‘YES’ or ‘NO’. Currently this functionality
is allowed only for LD – LOANS.AND.DEPOSITS.

ALT.ACCT.PARAMETER - Alternative Account numbers

This application specifies the structure of an alternative ACCOUNT numbers.

Figure 66 - Alternate Account Parameter

In practise where T24 has replaced an existing system it may be a short-term requirement to allow the
access to client accounts using the old account numbers. In order to allow this, a special parameter
file, ALT.ACCT.PARAMETER needs to be set-up. This tells T24 how the other system account
number structure was defined.

Once this is set up it is possible to enter the old account number on the ACCOUNT record in the field
ALT.ACCT.ID.

An index is kept in ALTERNATE.ACCOUNT, the id is the external system account number and the
single field GLOBUS.ACCT.NUMBER contains the T24 equivalent.

TEMENOS T24 User Guide Page 67 of 105

Accounts

Extending ACCOUNT type fields to enable IBAN and other account numbers
The standard maximum length of ACCOUNT type fields is 16. However, due to requirements to
enter extended account numbers, such as IBAN numbers, it is possible to extend this maximum limit
through the EB.OBJECT application.

Workflow to extend capacity of the ACCOUNT field is as follows:

Figure 67 - Defining Account number length on EB.OBJECT

On the ACCOUNT record for EB.OBJECT, the maximum length of input to an account type field is
specified. In the above example, it would then be possible to type up to 36 characters into account
type fields.

Then, in the application ALT.ACCT.PARAMETER, alternative account formats can be specified–

where a maximum length of fields may be up to the number specified in EB.OBJECT.

Figure 68 - IBAN alternate account numbering

TEMENOS T24 User Guide Page 68 of 105

Accounts

In CHECKDIDGIT.TYPE, a routine may be entered to validate the ALT.ACCT.ID entered.

Of course, multiple ALT.ACCT.PARAMETER records may be created, to allow various different

alternative account numbers.

POSTING.RESTRICT - Posting restrictions

This file contains various types of restrictions that may be defined, such as ‘Post No Debits’,
‘Whereabouts Unknown’.

The system will automatically close any ACCOUNT that has a posting restriction in the90-99 range of
90-99 as soon as all balances are zero. Posting restrictions in the range 80-89 are used for accounts,
which are pending closure.

Where an ACCOUNT has a value in the field POSTING.RESTRICT and attempts are made to pass
entries to it, an override message will be issued.

Figure 69 - List showing some of the possible Posting restriction types

TEMENOS T24 User Guide Page 69 of 105

Accounts

Referral

A referral is the reporting of an ACCOUNT movement or balance to an account officer

(DEPT.ACCT.OFFICER) when certain conditions are met. For example an account may be referred
when it exceeds a particular debit value, or when certain types of transaction are passed across the
account etc.

A referral is only the reporting of the account to the account officer by means of an overnight report. A
posting restriction (a stronger form of referral) should be used if an override message at input is
required.

The REFERAL table contains the pre-defined referral conditions. These are then loaded onto the
ACCOUNT record in the REFERAL.CODE field. Multiple referral codes may be specified on an
account.

Figure 70 - Referral record

ACCOUNT.CLASS - Defining internal and other accounts

This table file has two main types, ACCOUNT and CLASS.

TEMENOS T24 User Guide Page 70 of 105

Accounts

ACCOUNT.CLASS records with a RECORD.TYPE of ACCOUNT provide the CATEGORY code

portion when building an internal ACCOUNT number (such as netting suspense account).

The use of CLASS as the RECORD.TYPE is used to identify a group of ACCOUNT records (e.g.
under a heading like NOSTRO) by matching the account details against those held in the
ACCOUNT.CLASS record.

Figure 71 - ACCOUNT.CLASS for Nostro Accounts

When the RECORD.TYPE is ACCOUNT then the CATEGORY code must be valid and in the range
10000 to 19999.

Figure 72 - ACCOUNT.CLASS for Suspense

TEMENOS T24 User Guide Page 71 of 105

Accounts

When the RECORD.TYPE is CLASS the CATEGORY and SECTOR code fields are treated as multi
value associated fields. Either field may be null, but not both at the same time. Duplications of
CATEGORY and SECTOR code combined are not allowed within one entry on the
ACCOUNT.CLASS table.

The following records are among those permitted:

Figure 73 - ‘CLASS’ ACCOUNT.CLASS records

For accounts the following ids are valid.

TEMENOS T24 User Guide Page 72 of 105

Accounts

Figure 74 - 'ACCOUNT' ACCOUNT.CLASS records

AC.STMT.PARAMETER - Defaults for account statements

The purpose of this table is to define defaults for ACCOUNT statement details when opening new
ACCOUNT records.

This table determines whether the default ACCOUNT.STATEMENT record is set to produce
statements when there has been no movement, descriptive statements, interest and charges

TEMENOS T24 User Guide Page 73 of 105

Accounts

statements and advices and tax advices and the minimum number of months for a statement to be
produced if at all. If no record exists the default will be 'NO' and the minimum frequency will be 6
months.

These settings can of course be overridden on the ACCOUNT.STATEMENT record itself.

Figure 75 - AC.STMT.PARAMETER

STMT.GEN.CONDITION - Defaults for statement frequencies

When a new ACCOUNT is opened, an ACCOUNT.STATEMENT record, specifying the date and
frequency for printing account statements is generated automatically by the system. The default
frequency is determined by the STMT.GEN.CONDITION.

TEMENOS T24 User Guide Page 74 of 105

Accounts

table.
Figure 76 – STMT.GEN.CONDITION

TEMENOS T24 User Guide Page 75 of 105

Accounts

ACCOUNT.STATEMENT - Statement details for an individual account

When a new account is opened, an ACCOUNT.STATEMENT record is automatically generated by

the system. This specifies the date and frequency for printing statements, whether statements are to
be printed if there have been no movements and various other statement production options. Defaults
are taken from other parameter tables such as the STMT.GEN.CONDITION and
AC.STMT.PARAMETER but these can of course be overridden by input to this table.

Account statements may

be produced periodically as specified by frequencies in the
ACCOUNT.STATEMENT application or on-line on an ad-hoc basis. The following SWIFT message
types are available:

• MT940 – Customer Statement

• MT941 – Balance Report
• MT942 – Ad-hoc statement
• MT950 – Statement
• Message Type MT942

Non Printing of Internal Account Statements

ACCOUNT.STATEMENT is an application, which allows the printing of account statements for all
Accounts.

The PRINT.STMT field in ACCOUNT.STATEMENT is an optional input, and input can only be
made for Internal Accounts. Input can be Null, Yes or No.

Figure 77 - ACCOUNT.STATEMENT record for Internal Accounts

TEMENOS T24 User Guide Page 76 of 105

Accounts

Figure 78 - ACCOUNT.STATEMENT record for Customer Accounts

If the field PRINT.STMT is set to Null or Yes, the statement will be printed as normal. If however this
field is set to No, the printing of the account statement is bypassed (i.e. this indicates that the
statement will not be physically printed out but all associated tables will be updated normally, as if the
statement was printed).

The key to the table is an ACCOUNT number.

TEMENOS T24 User Guide Page 77 of 105

Accounts

Figure 79 - Statement settings for an account

SWIFT MT492

The ACCOUNT.STATEMENT application also allows for the production of a SWIFT MT942
messages. Three fields on the ACCOUNT.STATEMENT record control MT942’s:

SEND.MT942 -Must be ‘Y’ or ‘N’

MESSAGE.TIME - A multi valued field containing all the times during the day that the Message
is to be produced.
MESSAGE.TIME - The minimum value of a transaction that is to appear on the statement. Any
transactions below this amount will be included on the statement

TEMENOS T24 User Guide Page 78 of 105

Accounts

Figure 80 - SendingMT942

Figure 81 - Sending MT942

These message types can also be produced on an ad-hoc basis as detailed in the next section.

Ad-hoc Interim transaction (MT942) reports

A customer may authorise another financial institution to receive statements and transaction reports of
his accounts. There is a facility to produce Interim Transaction Reports (SWIFT MT942) on-line on an
ad-hoc basis. Requests are entered through the application DE.MT942.REQUEST where T24 will
produce an Interim Transaction Report on the account specified. Note the 'V' function is required to
invoke the message creation.

TEMENOS T24 User Guide Page 79 of 105

Accounts

Figure 82 - Requesting a MT942

ACCT.GROUP.CONDITION - Rules for accounts

Figure 83 – ACCT.GROUP.CONDITION record I USD

The record id for this parameter file is the condition group and the currency of the account(s). Rules on
deposits, withdrawals and premium interest applying to accounts belonging to condition group and
defined for specific currency are entered here.

Further the record id for the parameter file 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
processing and the new values of the parameters are passed into the active record using the values
from this request record.

TEMENOS T24 User Guide Page 80 of 105

Accounts

It is recommended that the copy function be used to create the request record from the active record
prior to changing any parameters.

Additionally, where the requirement exists to record and report transaction violations on an account or
accounts within a particular group, this may be achieved by defining the threshold permissible before
the violation occurs and the transactions eligible to trigger a violation. The following example
demonstrates how this may be achieved.

Figure 84 - Transaction restrictions

In the example above, for ACCOUNT.GROUP 1, the number of transactions, with a transaction code
of 2, 84 or 85, permissible within a statement period, may collectively add up to, but not exceed, 5
transactions. If this threshold (TXN.THRESHOLD) is exceeded, the account is in violation and this will
be recorded on the account violations file (AC.VIOLATION). The above example is set up to record
violations if more than 5 cash withdrawals or more than 3 cheque withdrawals occur within the
statement period defined for the account group into which this account falls.

The RETENTION.PERIOD field defines how long records remain on the AC.VIOLATION file before
being transferred to the history file, AC.VIOLATION.HIST. Additionally, this field also determines
when transactions are deleted from the history file. They will be deleted after twice the period defined.
For example, if '12M' is entered in this field, a violation record will remain on the AC.VIOLATION file
for 12 months; it will then be transferred to the AC.VIOLATION.HIST file. The record would then
remain on the AC.VIOLATION.HIST file for a further 24 months before being deleted.

In the example above, for ACCOUNT.GROUP 1, the number of transactions, with a transaction
code of 2, 84 or 85, permissible within a statement period, may collectively add up to, but not exceed,

TEMENOS T24 User Guide Page 81 of 105

Accounts

5 transactions. If this threshold (TXN.THRESHOLD) is exceeded, the account is in violation and this
will be recorded on the account violations file (AC.VIOLATION). The above example is set up to
record violations if more than 5 cash withdrawals or more than 3 cheque withdrawals occur within the
statement period defined for the account group into which this account falls.

The RETENTION.PERIOD field defines how long records remain on the AC.VIOLATION file before
being transferred to the history file, AC.VIOLATION.HIST. Additionally, this field also determines
when transactions are deleted from the history file. They will be deleted after twice the period defined.
For example, if '12M' is entered in this field, a violation record will remain on the AC.VIOLATION file
for 12 months; it will then be transferred to the AC.VIOLATION.HIST file. The record would then
remain on the AC.VIOLATION.HIST file for a further 24 months before being deleted.

If a single limit default field in ACCT.GROUP.CONDITION is set to 'Y', then for all new account
opened, under the group single limit field in account is defaulted with 'Y'.

NOTICE.WITHDRAWAL - Notices given on notice accounts

Some types of accounts can be set up to have notice withdrawal conditions. In such a situation for a
withdrawal to be effected on the account a notice must have been given that satisfies the notice
conditions set up on the ACCT.GROUP.CONDITION application. These notices are given through
this application.

Figure 85 – ACCT.GROUP.CONDITION record

TEMENOS T24 User Guide Page 82 of 105

Accounts

Figure 86 - Withdrawal Notice Parameters

NOSTRO.ACCOUNT - Nostro accounts

Figure 87 - Default Nostro Accounts

Default NOSTRO accounts for currency and application are entered in the file NOSTRO.ACCOUNT.
Defaults can be set for each application, even for transaction types within that application. FOREX
has a unique option where the dealer can enter a letter indicating which NOSTRO should be used,
these equate with the input order; so the first FX default would be A, the second B and so on.

TEMENOS T24 User Guide Page 83 of 105

Accounts

High Volume Account Performance

Introduction to high volume account performance

In response to the performance issues related to high volume of entries passed over the same
account and for a better through-put of high volume of transactions, sub account processing and
consolidation of entries allows;
• The ability to automatically distribute transactions across linked sub-accounts without need to
modify the main settlement account specified on the transaction.
• The ability to automatically create sub-accounts as required
• The ability to create net statement and category entries automatically and so reduce high
volumes of entries
• The ability to keep the detail behind net entries for detailed investigation
• Detailed entries can be archived frequently to reduce the size of the database

Account with High Volumes

Accounts with these high volumes of entries tend to be accounts used for internal purposes
• Nostro Accounts
• Clearing Accounts
• Internal accounts used for purposes such as inter-company accounting, reserve accrual, off
balance revaluation, suspense processing and general ‘wash’ accounts
In general these types of account have no requirement for balance checking and interest calculations.

SUB-ACCOUNT PROCESSING
The ACCOUNT application allows the entries for an account to be distributed automatically across
sub-accounts. The system will automatically allocate an entry to a linked sub-account within the
accounting sub-system processing. This will ensure that locking contention is minimised.
Sub-accounts linked to the main account are held in the cross-reference table AC.SUB.ACCOUNT.

Setting up a High Volume Account

If an account is defined as a high volume account record, to allow the sub-account processing a value
between 1 and 99 must be defined under the field MAX.SUB.ACCOUNT, which will define the
maximum number of sub-accounts that the high volume account can hold. If no value is specified the
account will be processed as normal.
In addition to this, a record should be created in AC.AUTO.ACCOUNT under the account category
to define how the system will automatically create the sub-account.

TEMENOS T24 User Guide Page 84 of 105

Accounts

Figure 88 – Setting up an account as a high volume account

Whenever a transaction (both real and forward accounting transaction) hits a high volume account, the
system will allocate the sub-account from the AC.SUB.ACCOUNT table on a random basis using
the maximum number of sub-accounts as the maximum value.
The STMT.ENTRY record will be used to store the original account number under the field
MASTER.ACCOUNT.

Automatic Creation of Sub Accounts

When the system attempts to allocate a sub-account number based on the maximum number of sub-
accounts, and finds that an account does not exist, a new account record will automatically be created.
The new account record will be created based on the master account record and will inherit the
following values from the main record:
• Customer
• Category
• Currency
• Account Officer
• Reconcile Acct
• Our Ext Acct No
• Dispo Officer

Additionally a new table AC.AUTO.ACCOUNT will allow definition by account category of additional
rules including:
• Additional fields to be mapped (e.g. Local reference values)
• Numbering rules to be applied for the account

When the sub-account is created, a record is also added automatically in ACCOUNT.STATEMENT

for that account. If the field OUR.EXT.ACCT.NO is set in the sub-account, the AGENCY record for
that customer is also updated.

TEMENOS T24 User Guide Page 85 of 105

Accounts

Numbering sub-accounts
When using Sub accounts with internal accounts and internal Inter-company accounting the Sub
accounts can be set up to increment using either the CATEGORY or SUFFIX part of the account
number. For example in a multi-book area an inter-company account will be formatted like;

USD-11500-0001-0033

If the field INT.ACC.TYPE in AC.AUTO.ACCOUNT is set to CATEG then when sub accounts are
automatically opened by the system, it is the CATEGORY section of the account number that will be
incremented, up to the MAX.SUB.ACCOUNT (defined in the master account). For example the above
account number will become:

USD-11501-0001-0033

However should SUFFIX be defined in INT.ACC.TYPE in AC.AUTO.ACCOUNT, then USD-11500-

0001-0033 would be incremented as USD-11500-0002-0033. However it is recommended that if
using SUFFIX with Sub accounts for inter-company accounting that the SUB.SIVISION code of the
Multi-book's be well spaced for example using 0100, 0200 rather than 0001, 0003 as this will effect the
logical creation of sub accounts.

AC.AUTO.ACCOUNT

Figure 89 – Setting up rules for sub account creation for a/c CATEGORY

TEMENOS T24 User Guide Page 86 of 105

Accounts

Numbering rule for sub account

The field NEW.NUMBER.RULE will indicate the system how to generate the account number for the
new sub account.
It can either contain the value “NEXT” in which case the system will allocate the next id using the
check-digit rule defined in the COMPANY record; otherwise, it can contain the name of a routine that
will return a new account number.
Inherited fields
Some fields will be inherited by the sub-accounts by default; however the sub account may inherit the
values of additional fields from the master account. The fields that the sub account will inherit must be
defined under the multi-valued field INHERITED.FIELD.

Fixed value
Some fields may hold a fixed value for sub accounts under a specific category, irrespective of the
value held in the Master account.
The associated fields FIELD.NAME and FIELD.VALUE allow the definition of the fixed value that
some fields will hold.
Any field defined with a fixed value will have priority over the inherited field, hence the field in the sub
account will hold the value defined in the FIELD.VALUE field.

Excluding sub account processing

Although the account is defined as a high volume account, some transactions may be excluded from
being distributed to sub accounts. This may be at application level or at transaction level.
This may be defined under the fields EXCLUDE.SYS.ID and EXCLUDE.TXN

Specific operation on sub account creation

A routine may be called to perform any other operation associated with the creation of the sub account.
This must be defined under the field CREATION.RTN

Processing transaction to a high volume account

The following is an example of processing a FUNDS.TRANSFER entry to a high volume account

TEMENOS T24 User Guide Page 87 of 105

Accounts

Figure 90 - FUNDS.TRANSFER entry to a high volume account

The entry has been distributed to a sub account which has been created automatically:

TEMENOS T24 User Guide Page 88 of 105

Accounts

Figure 91 - STMT.ENTRY distributed to sub account and MASTER.ACCOUNT hold value of original
account

The automatic creation of the sub account:

TEMENOS T24 User Guide Page 89 of 105

Accounts

Figure 92 - Sub account has been automatically created

Statement Printing
The account statements are generated by Sub Account; that is for each sub account there will be a
separate statement.

Nostro Reconciliation
Consult the Nostro Reconciliation User Guide for details of how sub-accounts will be handled

TEMENOS T24 User Guide Page 90 of 105

Accounts

Consolidation of Statement Entires

The field CONSOLIDATE.ENT in the ACCOUNT application indicates that an account is to raise
consolidated statement entries.

Figure 93 - AC.CONSOLIDATE.CODE linked to an account

To allow the consolidation of statement entries for a specific account, this field should contain a valid
record in the AC.CONSOLIDATE.COND application. This application is a parameter table that
defines simple rules for the consolidation of entries
AC.CONSOLIDATE.COND – Consolidation Parameters
The account for which consolidated entries should be raised, must be linked to a consolidation
condition defined in this table, the condition may apply:
• The type of entry that should be consolidated, i.e. forward or live or both may be defined under
field ENTRY.TYPE
• The field EXCLUDE.SYS.ID defines the system ids that should not be consolidated
• The field EXCLUDE.TXN defines the transaction codes that should not be consolidated
• The field EXCL.PROD.CAT defines the Product Categories not to be consolidated for P&L
entries
• The field EXCLUDE.RTN may hold a routine that will indicate if entry is to be consolidated or
not
• Additional fields in the entry to be used in the consolidation may be defined under the field
ADD.CONSOL.FLD
• The field NO.ENTRIES.START determines the number of entries that should be raised for the
day before consolidating for an account.

TEMENOS T24 User Guide Page 91 of 105

Accounts

Figure 94 – Setting up the parameter for consolidation entries

AC.CONSOLIDATE.COND – Default Option for Nostro and Internal account

If the field CONSOLIDATE.ENT is not set in the account record for Nostro and Internal accounts, then
the system will refer to a default record ‘DEFAULT’ in the AC.CONSOLIDATE.COND to determine
the rule for consolidation process.

TEMENOS T24 User Guide Page 92 of 105

Accounts

Figure 95 - 'DEFAULT' record in AC.CONSOLIDATE.COND

The NO.ENTRIES.START in the ‘DEFAULT’ record is set to 400, which means that consolidation of
statement entries will start once 400 entries have been raised for the day to both Internal and Nostro
accounts.

Consolidated Entry Data

The system will raise consolidated statement entries for those accounts specified, each consolidated
statement entry will be keyed by the following consolidated elements of the entry, each element is
separated by the “!” delimiter.
• Entry Type - S, C or F
• 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)

TEMENOS T24 User Guide Page 93 of 105

Accounts

• Product Category (P&L only)

Plus any additional elements defined in AC.CONSOLIDATE.COND

Example of FUNDS.TRANSFER entries consolidated under the same STMT.ENTRY

Figure 96 - First FUNDS.TRANSFER entry

Figure 97 – Second FUNDS.TRANSFER entry

TEMENOS T24 User Guide Page 94 of 105

Accounts

Figure 98 – Consolidated STMT.ENTRY for the FT entries

The detailed statement entries generated by the three FT entries have been consolidated based on
the consolidation criteria defined above.

The AMOUNT.LCY and AMOUNT.FCY from the detailed entries are added to the value in the
consolidated entry. A new EXCHANGE.RATE is calculated based on the value of the local and foreign
amounts.
The TRANS.REFERENCE and OUR REFERENCE in the consolidated entry contain the value NET-
consolidated id.
The original SYSTEM.ID is suffixed with the value NET – this will allow existing enquiries to drilldown
to the consolidated entry rather than the originating application since the contract reference will not be
present. The STMT.NO field will indicate the number of statement entries that have been consolidated.

Detailed Statement Entries

The system keeps the link between the main consolidated entry and the detailed entries in
STMT.ENTRY.DETAIL.XREF while the detailed statement entries are held in STMT.ENTRY.DETAIL.

STMT.ENTRY.DETAIL.XREF
In order to keep these records a manageable size in STMT.ENTRY.DETAIL.XREF every 200 detailed
statement entries under a consolidated statement, a new record is created and the sequence number
is incremented by one.

TEMENOS T24 User Guide Page 95 of 105

Accounts

The id to the STMT.ENTRY.DETAIL.XREF is the consolidated statement id-the sequence number

and each record will hold up to 200 statement entry ids.

Figure 99 - STMT.ENTRY.DETAIL.XREF showing the STMT.ENTRY IDS consolidated

STMT.ENTRY.DETAIL
The STMT.ENTRY.DETAIL application is a replicate of the STMT.ENTRY but which holds only the
detailed statement entries that have been consolidated. The Detail Id is the key to
STMT.ENTRY.DETAIL and it will hold the details of the statement entry.

The following shows the details of the two entries that have been consolidated:

TEMENOS T24 User Guide Page 96 of 105

Accounts

Figure 100 – Detailed entry for the first DETAIL.ID

TEMENOS T24 User Guide Page 97 of 105

Accounts

Figure 101 – Detailed entry for the second DETAIL.ID

Statement Printing

Although the statement entry is consolidated, the statement contains the contents of detailed entries.

Consolidation of Category Entries

CATEGORY may also indicate that consolidated P&L entries are to be raised if the
CONSOLIDATE.ENT field holds a valid record in the AC.CONSOLIDATE.COND.

TEMENOS T24 User Guide Page 98 of 105

Accounts

The system will then raise consolidated category entries for those categories specified; the detail of
the underlying entries will be maintained in a new file, CATEG.ENTRY.DETAIL. Details will be
linked to the consolidated entry by a cross-reference file CATEG.ENTRY.DETAIL.XREF.
The consolidated entries will be written to the CATEG.ENTRY file and will be the entries presented in
standard account statements and enquiries.

Archiving
The detailed entries that have been consolidated will be archived every six months. The detailed
entries are extracted from the consolidated statement entry id in the ACCT.STMT.PRINT. The
STMT.ENTRY.DETAIL record in ARCHIVE defines the archiving details for the detailed statement
entries.

Statement Print masking

It is possible to mask accounting entries, where entries have been posted incorrectly and had to be
reversed out, or other financial postings that customers do not want on their statements.

Masking is also necessary because some customers reconcile directly against the statements they
receive from the banks and unexpected entries can cause confusion to their reconciliation’s. This is
especially true when the statement is delivered electronically and the customer uses it to reconcile
internally within their computer systems.

Masking will only apply to statements only. The entry will not be removed from the account and the
transaction will not be deleted it, it just will not show on the statement.

Setting up the statement masking

A field called MASK.PRINT exists in STMT.ENTRY to indicate whether certain statement entries
should be masked from printing, or not. To update the MASK.PRINT field AC.PRINT.MASK allows
users to flag statement entries manually that customers do not want to see on their statements. The
selection of entries to be masked for a particular account will be assisted by the provision of
STMT.ENTRY enquiries.

Once the statement entries have been captured into AC.PRINT.MASK application, the system will
then perform routine validations on the selected entries, firstly to ensure the integrity of the selected
items and to also make sure that the net movement of the selected entries is zero.

Once all the routine validations have taken place, the statement print programs or formatting enquires
must now check the MASK.PRINT field on the STMT.ENTRY record, if the value of the field is true
then the entry should not be displayed.

TEMENOS T24 User Guide Page 99 of 105

Accounts

AC.PRINT.MASK

As mentioned before, the AC.PRINT.MASK application has been produced to allow users to go in
and manually flag certain statement entries that have to be omitted from customers’ statements. This
section will show you how to set up an AC.PRINT.MASK record and explain the rules and
validations of the application.

Figure 102 - AC.PRINT.MASK

First of all run the application AC.PRINT.MASK and capture and id which can be automatically
generated by setting up an AUTO.ID.START record for AC.PRINT.MASK and by also making sure
that the application exists in the COMPANY record under the PG.AUTOM.ID. Once you have
captured the id you will be required to capture the account number of the customer and the current
date in MASK.DATE. Enter dates in ENQ.START.DATE and ENQ.END.DATE. These dates are
captured to ensure that statement entries that are to be masked fall within the start dates and end
dates. If you do not enter any dates into these fields a default date of today will be captured in those
fields. The MASK field will indicate whether the statement entries should be masked and unmasked.
You can capture either “YES” or “NO” and which is mandatory. The MATCHED.TO field is used to
capture all the statement entries you wish to mask or unmask, however they must all be debit entries
or all credit entries. You cannot mix debit and credit entries in the same field. The same applies to the
MATCHED.FROM field. You can use STMT.ENTRY enquiries to pick the entries you wish to select to
update the relevant fields in STMT.ENTRY. There is an example below that explains how to run the
enquiries and to select; copy and paste the relevant entries into the MATCHED.TO and
MATCHED.FROM fields.

TEMENOS T24 User Guide Page 100 of 105

Accounts

Figure 103 - Example STMT.ENTRY

This is an example of all the statement entries that are associated with account number 0000001775.
To bring up this list you have to run an enquiry on the STMT.ENTRY application of all statements that
belong to the particular account that you want to mask.

Figure 104 - Individual entry

Once you have found the statement entry that you wish to mask or unmask for printing on the enquiry
list, you then double click on the statement entry and the full record for the statement entry will then be
displayed as shown in Figure 0-3. You then highlight the statement entry id at the top of the record
and right click on the mouse and copy the id.

TEMENOS T24 User Guide Page 101 of 105

Accounts

Once you have copied the statement entry id, you then go back to the running AC.PRINT.MASK
application, move your mouse to either the MATCHED.TO or MATCHED.FROM field, right click on them
and then paste the id into the field and hit enter. Once you hit enter, the fields TO.TOTAL and
FROM.TOTAL as well as the NET.TOTAL field will be updated with totals in the statement entry
record. Once again, make sure that your MATCHED.TO and MATCHED.FROM fields consist of either
all debit or all credit entries.

When all the entries have been captured you can then commit and authorise the record, but the
system will make sure that the net movement between the statement entries captured is zero.

Once the authorisation takes place the relevant STMT.ENTRY records will be either masked or
unmasked for printing at a later stage.

US Regulation D Compliance

In order to allow the record of any Regulation D violation on-line, the Core Accounting module has
been modified to facilitate this regional development, by allowing a locally developed accounting sub
routine to be defined.

This routine will accept accounting entries, and optionally return a list of override messages at the
input stage, i.e. for unauthorised entries.

The rule to generate the overrides is defined in the local subroutine, an example program namely
AC.TEST.NAU is provided.

Although other user processing may also take place, care must be taken to ensure system
performance is not affected.

Note: Original entries cannot be changed.

The core system will then process these overrides, including the possibility of logging them with the
DISPO module.

Setting up the routine

The routine must be defined an ‘S’ type in PGM.FILE.

TEMENOS T24 User Guide Page 102 of 105

Accounts

Figure 105 - Setting up the Local Routine

ACCOUNT.PARAMETER
The Core Accounting routine will fetch the local routine if it is defined in ACCOUNT.PARAMETER
under ACCT.NAU.SUBRTN.

Figure 106 - Defining the Local Routine in ACCOUNT.PARAMETER

Override Messages

When a transaction is being processed the Core Accounting routine will process all the system
overrides then will call the local routine and generate the local overrides.

As from the example program, an override message ‘HAVE A NICE DAY’ is generated at the
transaction input stage.

The example below shows a Funds Transfer input and the flow of the override message. Once the
system overrides have been raised then the local ones will be raised.

TEMENOS T24 User Guide Page 103 of 105

Accounts

Figure 107 – Override from local subroutine is raise “Have a nice day”

Internal Files

ACCT.ACTIVITY - History of account activity

This is an internal file containing details of account balances and activity, used to calculate interest
and charges. It is also used in the calculation of average balances in the Management Information
module.

Details are held in separate records for each account for each month in which there has been any
activity over the account or in which the value dated balance changes. Full details of all balance
changes are included as well as details of transaction activity by transaction code.

TEMENOS T24 User Guide Page 104 of 105

Accounts

Figure 108 - Record of account activity

ACCT.AVAILABILITY - History of availability of funds on Accounts

This is an internal file containing details of account balances, activity and availability of funds used in
penalty charge processing. It is also used in the correct implementation of some rules that place
restrictions on the movements on the accounts. These rules are specified on the
ACCT.GROUP.CONDITION application.

Details are held in separate records for each account.

TEMENOS T24 User Guide Page 105 of 105