Accounts - User Guide: Release R15.000

Accounts - User Guide
Release R15.000
June 2015
©2015 Temenos Headquarters SA - all rights reserved.
Warning: This document is protected by copyright law and international treaties. Unauthorised reproduction of this document, or any portion of it, may
result in severe and criminal penalties, and will be prosecuted to the maximum extent possible under law.
Table of Contents
Introduction 5
Purpose of this Guide 5
Intended Audience 5
Accounts Overview 6
Accounts Configuration Overview 7
ACCOUNT.PARAMETER 8
Types of Account 18
Client Account 19
Internal Account 23
Nostro Account 24
Defining Internal and Other Accounts - ACCOUNT.CLASS 25
Account Number Format 28
Client Account Number Format 29
Internal account number format 30
Multi Book 31
Multi Company 33
Single Company 35
Account input 37
Contingent Accounts 38
Set up of Contingent accounts 39
Customer Account Input 43
Multi Gaap Accounts 45
Nostro Account Input 46
Locking of Funds Blocked or Held Amounts 47
Credit checking (locked amounts) 48
Account Balances 50
EB.CONTRACT.BALANCES for an Account 52
Credit checking 54
Movements 55
Override Messages 56
Parameters 57
EB.AF.PARAM 58
EB.AF.PARAM.CHANGE 59
ACCOUNT, ACCT.GROUP.CONDITION and ACCOUNT.PARAMETER 60
Available Funds and Shared Balances 62
Rebuilding Available Funds 63
Account Closure 65
Example AC.PRE.CLOSURE.DETAILS 65
Example Account Closure 68
Example - Online Closure 71
Account Statements 73
Camt in T24 74
Prerequisites 75
Country Specific Camt Format 76
Camt Tags Supported by T24 77
Module Components 79
Camt Generation Process 91
Exception Handling of CAMT Messages 102
Accounts - User Guide - Release R15.000 - Page 2 of 207

Archiving of XML Statement Related Tables 104
Configuring the Content of the Camt Message 105
Glossary of Terms 120
AC.STMT.PARAMETER - Defaults for Account Statements 121
ACCOUNT.STATEMENT - Statement Details for an Individual Account 123
Non Printing of Internal Account Statements 125
STMT.GEN.CONDITION 126
Swift MT942 127
IX Module Related Changes 129
Overview 130
Structure of a Camt Statement 131
Accounts Turnover Reversal 134
Account Violations 138
Limits 140
Accounts with Notice Periods 141
ACCT.GROUP.EVENT 142
Additional Rules for Groups of Accounts - ACCT.GROUP.CONDITION 143
Alternative Account Numbers 145
Change of Main Customer 147
High Volume Processing 148
Introduction to High Volume Account Performance 148
High Volume Accounts 149
Overview 149
When to Use High Volume Accounts? 149
Inactive Accounts 152
Payment Netting 154
Accounting for Net Payments 155
Payment Netting Setup 156
Setting up the Payment Netting Suspense Accounts 157
NETTING.PARAMETERS 159
NETTING.AGREEMENT 160
CREATE.NETTING 161
NETTING.ENTRY 162
NETTING Application 164
Posting Restrictions 166
Referral 168
Standard Settlement Instructions 169
Statement Print Mask 171
AC.PRINT.MASK 172
Suppression of Unnecessary Overrides 174
Unauthorised Entries for Accounts 175
US Regulation D Compliance 177
Accounts Deal Processing Overview 179
Internal Files 180
ACCT.ACTIVITY - History of Account Activity 181
ACCT.AVAILABILITY - History of Availability of Funds on Accounts 182
High Volume Accounts 183
HVT Parameterization 189
Unauthorised Entries for Accounts Example 193

Trade Dated GL Balances 196
Trade Dated GL Balance for Credit Checking 197
Statement Processing 198
Services Overview 200
Enquiries and Reports Overview 201
Account Overdrawn 202
Overdraft Ageing 203
ACCT.OD.HIST 205
Enquiries and Reports Overview 206
Non Stop Processing Overview 207

Introduction
Purpose of this Guide

The Banking Framework User Guides provide a profound insight into the developments and changes to the Core Financial Products and Core
Financial Services of T24.
Intended Audience
This Banking Framework User Guides are intended for T24 Customers and Internal Stakeholders to stay informed of the latest developments
and changes on the Licensed Core Financial Products and Core Financial Services of T24, which are constantly revised and upgraded to leverage
new technologies and new technical architectures.

Accounts Overview
The Account, Interest and Charges User Guide has been split into several parts to make finding the relevant information easier, as follows:
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)’
Refer to these user guides for further details:
The ACCOUNT module (and its Interest and Charges routines) caters to the creation, maintenance and control of all types of accounts handled
by T24. It also provides:
l Calculation of interest on client accounts.

l Calculation of premium interest on client accounts.
l Calculation of charges relating to the maintenance and servicing of accounts.
l Pre-notification of debit interest and/or charges on client accounts.
l Production of statements, overdraft and referal reports.
Accounts can be classified as one of the two types, client accounts or internal accounts. Client accounts are those owned by an external cus-
tomer such as current accounts, savings accounts and so on. 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.

Accounts Configuration Overview
The following pages will address:
l ACCOUNT.PARAMETER
l Types of Account
l Defining Internal and other accounts - ACCOUNT.CLASS
l Account number format
l Account Input
l Locking of Funds (Blocked or Held Amounts)
l Account balances
l Account Closure
l Account Statements
l Account Turnover Reversal
l Account Violations
l Accounts with notice periods
l ACCT.GROUP.EVENT
l Additional rules for groups of accounts - ACCT.GROUP.CONDITION
l Alternative Account Numbers
l Change of Main Customer
l High Volume Processing
l Inactive Accounts
l Limits
l Payment Netting
l Posting Restrictions
l Referral
l Standard Settlement Instructions
l Statement Print Masking
l Suppression of unnecessary overrides
l US Regulation D Compliance

ACCOUNT.PARAMETER
The ACCOUNT.PARAMETER record contains high-level specifications for the ACCOUNT application. For example:
l Number of days forward for cash-flow processing.

l Whether accounting is performed on a value date or booking date basis.
l Whether accounts can be referenced by an alternative ID or not.
l Whether the customer number must form part of the account number.
l Whether payments can be netted.
l How settlement defaulting is to take place.
l Whether to update ENT.TODAY files or not based on the ENT.TODAY. UPDATE field value. The value of NULL will be defaulted,
which will allow updates to ENT.TODAY files
l Whether to use the future BOOKING.DATE option through OFS.CLEARING or not, is based on the RAISE.VD.ENTRIES field value.
The value of NULL will be defaulted, which can be set as YES to allow the use of future BOOKING.DATE in OFS.CLEARING. Once set
to YES, this becomes a ‘no change field.’
There is only one record, with an ID of SYSTEM.

Posting Restrictions
The field POSTING.RESTRICT in the ACCOUNT.PARAMETER defines the behaviour of the POSTING.RESTRICT field set at underlying
ACCOUNT level at the time of ACCOUNT.CLOSURE.
This field will accept the following options:
l Single - Upon input of the ACCOUNT.CLOSURE, any existing value/multivalue is removed and the field POSTING.RESTRICT of the
Account is populated with the value of 90.
l Multiple/None - The POSTING.RESTRICT value for ACCOUNT.CLOSURE is appended along with the existing values in the under-
lying account record.

Refer to the following section of the user guide for an example - Client Account
The existing functionality of ACCOUNT.PARAMETER table is modified and new fields are added to allow the set up for ACCT.ACTIVITY to be
updated using the Exposure date of a credit movement. It is also possible to switch from one Accounting system to another accounting. Only
the new transactions are applied at a System level or at a Category range. Else, the existing functionality would be continued. The statement
entries, which are raised after the Exposure Date setup is turned on, will have the value, EXPOSURE.DATE in the field TDGL.DETAILS for cal-
culation of interest, only for credit transactions. If the setup is turned off, then the field has the value VALUE.DATE
l It is required to set the values in ACCOUNT.PARAMETER to allow the setup for ACCT.ACTIVITY to be updated using the Exposure
date of a credit movement.
l Based on the above set up, the system first checks the Category from the Entry fits in the Category Range, and then checks if there is
anything set-up in EXP.UPD.ACCT.ACTIV.CAT
l If not defined at the Category Range, then it checks at the system level under EXP.UPD.ACCT.ACTIV and restricts only to the men-
tioned category.
l If the above setup is not defined, the set-up is a ‘VALUE.DATE’ by default.

Scenarios
Scenario 1:
The new fields are added in the ACCOUNT.PARAMETER. Based on the set up done and the category defined in the new fields, the
ACCT.ACTIVITY record gets updated.

Scenario 2:
The EXP.UPD.ACCT.ACTIV is set as YES in ACCOUNT.PARAMETER and CONSOLIDATE.ENT is also set as YES.
When validating the ACCOUNT.PARAMETER the system throws an error message "EXP.UPD.ACCT.ACTIV input not allowed when
CONSOLIDATE.ENTRIES is 'yes'.

Scenario 3:
FT transaction is made with the value date of 4th May and with the Exposure date as 6th May. Now, rebuilt the exposure date using
AC.REBUILD.EXPOSURE application for a transaction. The ACCT.ACTIVITY table is updated based on the MODIFIED exposure date in
credit account and ACCT.ACTIVITY table is updated with the value date in debit account and checks if the STMT.ENTRY is raised.

Scenario 4:
The transaction is made between accounts when the category does not fall under the mentioned fields EXP.CAT.START AND EXP.CAT.END.
In this case, the precedence is for the Value date.

Types of Account
The following types of account can be entered in T24:
l Client Account
l Internal Account
l Nostro Account

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 customers change 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 char-
acteristics. Typically, this would include the debit/credit interest rates, interest and charges capitalisation frequencies, statement production
cycle, other account group conditions and so on. 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:
l Posting Restrictions
l Referral Conditions
l Alternate Account ids
l Mnemonic codes
l Joint account holders

l Liquidation of interest to another account
l Pre-Notification of debit interest due
l Charges capitalised to another account
l Pre-Notification of charges due
l Interest and Charges settled in currencies other than the account currency
l Combining balances across accounts before interest calculations
l System information fields such as balances and so on
An example of a simple current account is shown:
In the above example, the account 25976 has a field MNEMONIC that contains a value of 'AIREUR'. This mnemonic can be entered into any
standard T24 ACCOUNT field and is translated automatically into the correct ACCOUNT number.
The field POSTING.RESTRICT is a multivalue field in account and can accept any number of posting restrictions that the Bank may wish to
set. Subsequently, any of the POSTING.RESTRICTs other than system populated (For example 90 for ACCOUNT.CLOSURE) can be removed
by the Bank, as and when the obligation toward the Bank has been met by the customer.

When a transaction is entered for the account, all of the posting restrictions that have been set on the account will be displayed to the user.
Including those set at the CUSTOMER level).
In the above transaction, all the relevant POSTING.RESTRICT applicable to both the debit and credit Accounts involved in the transaction are
displayed.
Posting Restrictions at Account Closure

During the closure of the ACCOUNT, the value of the field POSTING.RESTRICT set in ACCOUNT.PARAMETER defines the availability of the
existing POSTING.RESTRICTs in the ACCOUNT.
For example:
When the field POSTING.RESTRICT in the ACCOUNT.PARAMETER is set to Multiple or None, when an ACCOUNT is subjected to the
ACCOUNT.CLOSURE processing, the POSTING.RESTRICT code for closure -90 is appended to the existing set of POSTING.RESTRICTs in
the account, as shown in the following screenshot:

When the field POSTING.RESTRICT is set to Single in the ACCOUNT.PARAMETER, when an ACCOUNT is subjected to the
ACCOUNT.CLOSURE processing, the POSTING.RESTRICT code for closure "90" overwrites the existing set of POSTING.RESTRICTs in the
account, as shown in the following screenshot:

Internal Account
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. As 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.

Nostro Account
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 as the real account owner is you. An
example of a NOSTRO account is shown below.
When setting up a Nostro Account the client of the ACCOUNT should not receive a statement, or debit/credit advices. These should be re-dir-
ected to your reconciliations 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 prevents any advices
for this account being sent to your correspondent.
If the 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 the 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,
refer to the User Guide chapter for that module.

Defining Internal and Other Accounts - ACCOUNT.CLASS
This table file has two main types, ACCOUNT and CLASS.
ACCOUNT.CLASS records with a RECORD.TYPE of ACCOUNT provide the CATEGORY code portion when building an internal account num-
ber (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. This screen shot shows an example ACCOUNT.CLASS record for Nostro
accounts.
When the RECORD.TYPE is CLASS, the CATEGORY and SECTOR code fields are treated as multi value associated fields. Either of the fields
can 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.
When the RECORD.TYPE is ACCOUNT, then the CATEGORY code must be valid and in the range 10000 to 19999. The following screenshot
shows the ACCOUNT.CLASS record for SUSPENSE.
The following records are among those permitted:

NOSTRO Identifies a Nostro account
VOSTRO Identifies a Vostro account
BRANCH Identifies an account belonging to a branch of company processed
BANK Identifies an account belonging to a bank
MORTGAGE Identifies a Mortgage account
MGDEPOSIT Identifies a Mortgage Deposit account
SAVINGS Identifies an account as a Savings account
For accounts, the following IDs are valid.
Key Description
SUSPENSE DATA.CAPTURE, which have not been authorised.
DIFFERENCE DATA.CAPTURE entries to balance a batch.
SUSPCREDIT Accounting suspense entries when the original entry cannot be posted due to the ACCOUNT not being
present or an override condition has not been met.
SUSPDEBIT
SUSPLMMCR Loans and Money Market entries when the true ACCOUNT is not yet known for the payment or receipt.
SUSPLMMDR
SUSPFXCR Foreign Exchange entries when the true ACCOUNT is not yet known for the payment or receipt.
SUSPFXDR
EXCHADJ Unrealised profit and loss produced by the revaluation of foreign exchange contracts.
EXCHALFWD Used to post the P & L produced by the revaluation and contingent balances in a value dated accounting sys-
tem.
RESFWDCR To be used by the FOREX system when posting the interest accruals on Foreign Exchange contracts using
the straight line or Interest revaluation method.
RESFWDDR
RESSWAPCR
BROKER Used to identify the provision account to be used to book the brokerage
NETTING Suspense account for net payments.
SUSPSCDR Suspense account, which the Securities module will use.
SUSPSCCR
SCDIFF
SUSPFRACR Suspense account which the FRA.DEAL module will use
SUSPFRADR
SUSPFTBULK Suspense account which the FT module will use for bulk transfers and incoming deals.
SUSPFTINWD
SUSPPD Wash through account used by accounting for past due payments
SUSPSLCR Suspense account, which the Syndicated Loans module will use.
SUSPSLDR

TFLC Suspense account, which the LC module will use
LCAMORT
LCDIFF
PLCLOSE Used at year end closing of PL
INTERCO Used for passing entries between inter-company accounts
ACCOUNT' ACCOUNT.CLASS records

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.
l Client account number format

l Internal account number format

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:
l ACCT.CHECKDIG.TYPE
l ACC.BKNO.PREFIX
l ACCOUNT.MASK
Refer to the help text on these fields for the settings you require.
For extended account numbers longer than 16 characters, the input length must be defined in the EB.OBJECT application, in the field
MAX.LENGTH.
The ACCT.CHECKDIG.TYPE 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, fol-
lowed 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 two 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 Where a local subroutine performs the check digit calculation.

name’
'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 . The following are the different
structures that can be set up:
l Multi-book
l Multi-company
l Single company

Multi Book
In a Multi-Book environment the simple internal account number format is CCYCCCCCNNNNBBBB
l CCY is the Swift currency code of the account e.g. EUR, USD
l CCCCC is a category code in the range 10000 – 19999
l NNNN is a sequential number in the range 0001-9999
l BBBB is the sub division code of the company the account belongs to
In the above example, the sequential number is the till ID.
Position Account format

Position account format is CCYCCYCCCCCDDSSBBBB:
l The first CCY is the currency code of the account.

l The 2nd CCY is the other currency of the Position relationship. (see below)
l DD is the DEALER.DESK (00 default DEALER.DESK) for which the accounts are being maintained
l SS is a sequential number that allows access to sub account processing if required
l BBBB is the sub division code of the company the account belongs to.
CCYCCY - If the local currency is USD and there is a transaction in EUR, then two accounts need to be updated, the EURUSD and USDEUR.
l The EURUSD account is the EUR account with the amounts signed as for EUR.
l The USDEUR account is a local currency account with the opposite sign to that for the EUR.

For dealer desks, which are non numeric, the first two digits of the DEPT.FOR.REVAL are used for DD part of the account number. Note that
the DEPT.FOR.REVAL is taken to be a four digit number with leading zeros added if it is less than four digits. For example, if the
DEPT.FOR.REVAL is 998 then this is expanded to 0998. The system uses 09 for the account number.
The SS sequence number is used to allow for sub account processing. This uses these two digits in the range of 01 to 99. Thus for position
accounts there is a maximum of 98 sub accounts.
The intercompany account format is CCYCCCCCNNNNBBBB
l CCY is the Swift currency code of the account e.g. EUR, USD.
l CCCCC is a category code in the range 10000 – 19999 (intercompany category code).
l NNNN is the subdivision code of the other company in the transaction.
l BBBB is the sub division code of the company the account belongs to.
This screen shot shows the Inter-company account between lead company and book.
Some fixed internal ACCOUNTrecords are required by T24 applications and must exist prior to entering any transactions on these applic-
ations. These are listed in the ACCOUNT.CLASS records and are detailed in the field RECORD.TYPE. It is recommended that the local cur-
rency 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.

Multi Company
The Internal and position account numbers remain as above. Due to the nature of the environment, there is the addition of inter-company
accounts.
The format of these accounts are:
l NNNN is the sub division code of the other company in the transaction. Located on the COMPANY record.
The following screen shots show the sub division codes for the companies.

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

Single Company
The Internal account number format will be CCYCCCCCNNNN:
l NNNN is a sequential number in the range 0001-9999
This example shows an Internal Account ID structure in a Single company environement
Position Account
The Position account number format will be CCYCCYCCCCCDDSS:
l The first CCY is the currency code of the account.

l The 2nd CCY is the other currency of the Position relationship.
l DD is the DEALER.DESK (00 default DEALER.DESK) for which, the accounts are being maintained
l SS is a sequential number, which will allow access to sub account processing
This is an example of a position account in a single company environment.

CCYCCY - If the local currency is USD and there is a transaction in EUR, then the two accounts, which need to be updated are, the EURUSD
and USDEUR.
l The EURUSD account is the EUR account with the amounts signed as for EUR.
l The USDEUR account is a local currency account with the sign opposite to that of the EUR.
When position accounting is to be run, it is recommended that only numeric dealer desk IDs are used, as the dealer desk ID is used in the
account number ID for the position account.
However, for dealer desks, which are non numeric, the first two digits of the DEPT.FOR.REVAL are used for DD part of the account number.
For example, dealer desk is TR, DEPT.FOR.REVAL is 1899. The system will use 18 for the account number format. Note that the
DEPT.FOR.REVAL is taken to be a four digit number with leading zeros added if it is less than four digits. For example, if the
DEPT.FOR.REVAL is 998, then this is expanded to 0998. The system will use 09 for the account number.
The SS sequence number is used to allow for sub account processing. This uses these two digits in the range of 01 to 99. Thus for position
accounts there is a maximum of 98 sub accounts.

Account input
l Contingent Accounts
l Customer Account input
l Multi GAAPS accounts
l Nostro Accounts

Contingent Accounts
It is sometimes required to keep balance information for reporting purposes that is below the line (contingent). To allow 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 Cap-
ture 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 con-
tingent account.

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 con-
tingent account, for limit unutilisation/utilisation entries.
ACCOUNT.CLASS
For unutilised/utilised processing then three ACCOUNT.CLASS records , namely OFFLIMIT, UTILLIMIT and OFFSPINT should be created.
They have to be opened in the 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.
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-con-
tingent account groups are set up.

The field CONTINGENT.INT that is found in both the ACCT.GROUP.CONDITION and ACCOUNT records indicates whether the interest cal-
culated 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:
l “B” to indicate that non-contingent (on balance sheet) interest is to be generated for this account.
l “O” will indicate contingent interest; off balance sheet interest is generated.
l “C” will indicate that contingent interest will be calculated only and will therefore not be posted or appear or any balance sheet.
l “I” indicates that the contingent account is internal and therefore no interest is generated
l “Null”, if this field is not populated then the account is a non-contingent account
The following screen shot shows an 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.
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 unutilised/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, should a credit 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.
LIMIT
The contingent account to which the unutilised/utilised amount of a limit is to be swept is specified in the LIMIT application, in the
UNUTIL.ACCT/UTIL.ACCOUNT fields. It is from here that the current unutilised/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.
This screen shot shows an 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 in DATE.CAPTURE the entire batch must be of the same type.

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.
Some details such as the account title, customer who owns the account, CATEGORY and CURRENCY, are input at this time. However, extens-
ive 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 the majority of the processing characteristics defaulted from group level parameters. Consequently, when these char-
acteristics 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.
The types of characteristics that can be set up on the related parameters include:
l Interest rates and methods

l Interest capitalisation frequency
l Statement generation
l Charges
l Posting restrictions

l Premium Interest rates methods and capitalisation frequency
l 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 from that for private clients. This can 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.

Multi Gaap Accounts
Internal Accounts are needed for setups where multiple financial reporting is performed, for example IAS, IFRS or other forms of local report-
ing. To distinguish these accounts and their entries from other reporting systems, they must be setup with the correct POSITION.TYPE to
match the reporting system; see FX.POS.TYPE.
The CATEGORY used for the internal account must also have the correct POSITION.TYPE to match the reporting system.

Nostro Account Input
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.
However the file NOSTRO.ACCOUNT can be setup to default nostro information.
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 the NOSTRO that should be used, these equate with the input order; so the first FX default would be A, the second B
and so on.

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.
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.
The following example shows 10,000 being locked on account 34517 from the 30 Nov.
The ACCOUNT application shows a ladder of locking events applied to that account, and automatically includes 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. The following
example shows the account record 34517 after the AC.LOCKED.EVENTS record has been authorised with a locked amount of 10,000.00.
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.
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
results in the locked amount for the common dates in the ladder being the sum of the LOCKED.AMOUNT fields for those periods.
l Credit checking

Credit checking (locked amounts)
When an AC.LOCKED.EVENT record is raised for an account, if the current balances are already below the locked amount, the credit check is
done and an override message displays to the user.
Exact functionality of this feature depends 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, AVAILWORK or FORWARD, then the system uses the worst-case
scenario. The working balance or working plus today’s forward movements is checked against the highest amount in the locking ladder only
and an override generated as applicable.
Future overdraft check
Single Accounts
The system checks all of the available balances within the available funds ladder against the locked events ladder and generate override mes-
sages 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 falls 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 is written to history and deleted. Hence the Account
record is updated accordingly and no longer holds that locked amount.
Limit checking with locked amounts

If an account has locked funds, then any transaction input or locked funds input triggers the system to check the Balance available in the
Account against the Locked funds.
The system also allows the option to include the Limit in the Locked amount checking. The locked amount check is done on the current
balance and then on the future cash flows if there are any. If Locked amount checking with Limit is allowed, then the Limit or Balance avail-
able refers to Working.Balance or T24 Available Balance after taking the locked amount and Limit into consideration.
This functionality may be set at ACCOUNT.PARAMETER, ACCT,GROUP.CONDITION or on an individual ACCOUNT record using the field
LOCKED.WITH.LIMIT. The default setup is to ignore limit for locked amount processing. Priority is given to the set up at the lowest level.
The locked amount check is as follows:
l Locked amount check is done on current balance or current available limit against the worst locked balance. If there is any shortfall,
an override is raised:
Override ‘ACCT.BAL.LT.LOCKED’ is raised for an account with no limit or if Limit is not allowed on Locked amount checking.
OR
Override ‘LIMIT.WORKING.LT.LOCKED’ is raised for an account with a Limit and limit is allowed on Locked amount check-
ing.
l If there are any future cash flows, then the locked amount for future cash flows is done against the locked balance prevailing on the
Available date ladder.
l If the Available date is less than the date of the worst locked amount, and there is a shortfall then an override is raised:
Override ‘AVAILABLE.LOCKED.OVERDRAFT’ is raised for an account with no limit or if limit is not allowed with locked
amount checking.

OR
Override ‘AVAIL.LOCKED.LIMIT.OVERDRAFT’ for an account with a limit and limit is allowed with locked amount checking.
l If Available date is greater or equal to date of the worst locked Amount then the shortfall on that date is compared to the one from cur-
rent Balance check and an override is raised if the shortfall is worse.
l If the shortfall on Availble funds is greater than the shortfall on Working Balance, then the worst shortfall is kept.
The content of the following overrides, triggered from AC.LOCKED.EVENTS input, may be changed by User if Locked amount checking with
Limit is set:
Override ‘ACCT.BAL.LT.LOCKED.LIMIT’ for check on current balance
Override ‘AVAIL.LOCKED.LIMIT.OVERDRAFT’ for check on future cash flows
l With Locked amount checking with Limit on, if the Limit is expiring within the Available funds ladder or the Locked amount ladder,
then an override is raised to indicate that the Limit is expiring:
Override ‘AVAIL.LIMIT.LOCKED.EXPIRING’ to indicate that the Limit is expiring
Example - Credit Checking

Account Balances
The following balances are held on the EB.CONTRACT.BALANCES record for the individual account
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.
this feature refer to the following sections in the user guide (Local Clearing, System Tables and Teller).
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 Nostro's 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 at the start of day processing on the appropriate
date.
this feature refer to the following sections in the user guide (Local Clearing, Application Accounting, System Tables and Teller).
AVAILABLE.BAL
Through the Available Funds functionality, T24 will identify if any movements or transactions will generate a deficit of cash in a client's
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 from 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 The exposure date is the date on which a credit entry is included in the cleared balance of an account.
Date
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 when the transaction affects the available funds.
Booking Date The booking date is the date on which the transaction has been processed.
Available Available funds balances are held for all forward dated and value dated account movements up to the number of calendar
Funds Win- days forward from today as specified on CASH.FLOW.DAYS in ACCOUNT.PARAMETER.
dow
l BOTH - Unauthorised debits and credits to make up available balance

l NONE - No unauthorised movements to update available balance
l DEBITS - Only unauthorised debits to make up available balance
l 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.
Open Available Balance

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

EB.CONTRACT.BALANCES for an Account
All the transactional balances and data are held on the EB.CONTRACT.BALANCES for an account. The account record holds static account
information.The following is an Account record and the EB.CONTRACT.BALANCES record for that account.
The corresponding EB.CONTRACT.BALANCES record for account 66093905.

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 through the
CREDIT.CHECK field in ACCOUNT.PARAMETER, the options are as follows:
Null or WORKING l The update of available funds ignores unauthorised credits.

l Overdraft checks use only working balance.
l Future cash flow check uses the Available balance ladder as from the value/exposure date of the trans-
action.
FORWARD l Same as above, except that overdraft uses WORKING.BAL + FORWARD.MVMTS for today
AVAILABLE l The update of Available funds uses the AVAILABLE.BAL.UPD to decide how the available balance is
to be updated.
l There is no overdraft check.
l Future cash flow check uses available balance ladder as from the value/exposure date.
AVAILWORK l The update of the Available funds uses AVAILABLE.BAL.UPD.

l The overdraft check uses WORKING.BALANCE only.
l Future cash flow checks use Available balance ladder as from the value/exposure date.
AVAILFWD l The update of Available funds uses AVAILABLE.BAL.UPD.

l The overdraft check uses WORKING.BAL + FORWARD.MVMTS.
l Future cash flow check uses Available balance ladder as from the value/exposure date.
This field may be left blank l In this case, the ‘Working’ option applies.
This option is also available in the ACCT.GROUP.CONDITION and ACCOUNT application in the following order:
l ACCOUNT – a flag set here always takes precedence over a flag set elsewhere.
l ACCT.GROUP.CONDITION (If ACCOUNT is blank).
l 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 Avail-
able 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.

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:
l AV.AUTH.DB.MVMT - authorised debits

l AV.NAU.DB.MVMT - unauthorised debit movements
l AV.AUTH.CR.MVMT - authorised credits
l AV.NAU.CR.MVMT - unauthorised credits
See the section on EB.AF.PARAM .for additional information.

Override Messages
Available Balance Excess

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

An available balance overdraft override message is 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 be negative as of the value date of the transaction.
Available Balance Limit Excess

An available balance limit excess override message is 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 is 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 is raised if an account’s balance that has an AC.LOCKED.EVENTS record, falls
below the level of the locked amount.

Parameters
l EB.AF.PARAM
l EB.AF.PARAM.CHANGE
l ACCOUNT, ACCT.GROUP.CONDITION and ACCOUNT.PARAMETER
l Available Funds and Shared Balances
l Rebuilding Available Funds

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 takes priority over whatever is set for that application level.
In the above example, blocking parameters have been set for all unauthorised credits and debits within DC (DATA.CAPTURE).
If an unauthorised transaction is blocked, then neither the movements nor the available balance are updated and also no credit check is made
for that transaction.
The parameters present in this application are the ones that are 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. The 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
The screen shot shows the available funds Parameter Change for Data Capture
From the example
Application
The first two fields define the blocking parameters for the application
l Having the field AVAIL.BAL.NAU.DR set to blank means that all unauthorised debits for DC should update the available funds move-
ments and the available balances and also credit check should be made.
l Having the field AVAIL.BAL.NAU.CR set to ‘NO’ means that none of the unauthorised credits for DC should update either avail-
able 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.
If the field AVAIL.NAU.DR were set to ‘NO’ then no un-authorised miscellaneous debits in DATA.CAPTUREwould 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 takes today’s date unless a future date is input.
Once the parameters have been set in EB.AF.PARAM.CHANGE, depending on the effective date, they are 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, ACCT.GROUP.CONDITION or ACCOUNT.PARAMETER for the available funds processing.
The field CREDIT.CHECK defines on which balance the credit check is to be made, the possible values are:
l WORKING or NULL (blank)

l FORWARD
l AVAILABLE
l AVAILWORK
l AVAILFWD
The field AVAILABLE.BAL.UPD defines the unauthorised movements that are included in the AVAILABLE.BAL field that will be used for credit
checking:
l BOTH-Indicates that both unauthorised debits and credits make up available balance
l NONE - Indicates that no unauthorised movements update available balance
l DEBITS - Indicates that only unauthorised debits make up available balance
l CREDITS - Indicates that only unauthorised credits make up available balance

The following order of priority will be applied by the system:
l ACCOUNT
l ACCT.GROUP.CONDITION
l ACCOUNT.PARAMETER

Available Funds and Shared Balances
If an account is a member of a shared balances group then an exposure-dated ladder is 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 asso-
ciated with that group. When an online debit transaction takes place, the ladder is updated with the transaction amount for the appropriate
date. The system checks to see if there is an overdraft. If so, then an override message is generated.
Refer to the Liquidity Management User Guide for additional information.

Rebuilding Available Funds
In order to use the available funds functionality, the available funds ladder must be built for accounts with existing future transactions; oth-
erwise only new transactions will be reflected in the available funds. The application AF.REBUILD.REQUEST allows the rebuild to be done at
three different levels:
l Individual accounts
l Account group level
l All accounts
This screen shot shows the AF.REBUILD.REQUEST for account 19027.
The rebuild will then take place during the COB.
The AF.REBUILD.REQUEST can also be used to rebuild the available funds ladder if any data corruption is suspected.

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, set-
tlement account and the posting restriction to be placed on the account record.
In addition to ACCOUNT.CLOSURE, the AC.PRE.CLOSURE.DETAILS application can be used to simulate a closure on the account, no actual
accounting entries are raised from this application, it is for information purposes only. The application will calculate settlement amounts, pro-
duce a list of errors or override messages that will prevent an account from being closed by ACCOUNT.CLOSURE.
This application can only be used with the V and S function.
Example AC.PRE.CLOSURE.DETAILS

This functionality has been added to the model bank enquiries:
l ACCOUNT.CLOSURE
l ACCOUNT.CLOSURE.HP
l TELLER.ACCOUNT.CLOSURE
From the RETAIL MENU>ACCOUNT.CLOSURE>Account Closure

Enter the account number in to the selection and click Find.
The system will return the following screen, click on the new simulation button, as shown below:
An AC.PRE.CLOSURE.DETAILS record has been generated for the account 13037, with all the relevant closure information, Verify the record.
The override field contains the details of any actions that are required that prevents the account from closing. In this example, the account
13037 is part of a SEC.ACC.MASTER.

Example Account Closure
The example screen shows the ACCOUNT.CLOSURE record where the account will be closed during the Close of Business.

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 on 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, that settles 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 raises the relevant entries and moves 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 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 and the ID is the ACCOUNT number.
This record holds information that is used in the TELLER transaction and passes 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.CLOSURErecord should be
authorised, and the account will be closed and moved to history.
The system will not allow an account to be closed if it meets any of the following criteria:
l Part of a SAM
l Direct Debit
l If it is a liquidation account
l Interest compensation account
l Charge account

l All-In-One account
l Part of a sweep account
l Part of a cash pool
l Not in current company
l Part of collateral
l Unauthorised AC.PENDING exists
l Blocked using AC.BLOCK.CLOSURE
l Closure should not be flagged when account is in suspense
Click here for an Example of Online Closure

Example - Online Closure
The following is an example where Teller is used to close an account online. The ACCOUNT.CLOSURE record has the field CLOSE.ONLINE
set to Y and CLOSE.MODE is TELLER

Account Statements
Account statements show details of all entries over the ACCOUNT since the last statement. Entries are listed in transaction date sequence and
can show both transaction date and value date. There are various parameters, which will control the creation, frequency and content of the
account statements. These are:
AC.STMT.PARAMETER High level Parameter
STMT.GEN.CONDITION High level parameter
ACCOUNT.STATEMENT Account level

Camt in T24

Prerequisites
The Camt solution has been packaged into the T24 ISO20022 XML Account Statement Module (‘IX’ - ISO20022 Statement). The product ‘IX’
must be installed to use the Camt statement functionality.

Country Specific Camt Format
The Camt message produced by T24 is aligned with the Dutch specific usage rules as set by the Dutch Banking Association (NVB).
The NVB guidelines include the usage rules for the reporting of SEPA credit transfers and SEPA direct debits. The SEPA details required under
NVB are reported in the Camt statement subject to the availability of the required information in T24.
Note: Other country specific regulations need to be requested with requirements to evaluate whether those usage rules can be accommodated.

Camt Tags Supported by T24
Each building block of the Camt message has its own list of Tags to hold specific information for the statement. The tags have the following
attributes:
l Occurrence: Mandatory or Optional and Single or Multiple occurrence

l Value: Defined as per ISO20022 or may be configured by Account service provider
Out of all the Camt tags defined under ISO20022, T24 will support the following:
l All Mandatory tags

l Some Optional tags with non SEPA related details
l The Optional tags that are required under the NVB usage rules to report additional SEPA details from an underlying PACS message
The tags are defined internally using the T24 naming convention and are mapped to the ISO20022 Camt schema during the data trans-
formation process (please refer to the section ‘Camt generation process’ for more details on data transformation).
Mandatory Tags Supported

The following table shows the high level mandatory tags that are supported by T24 with an indication of the tags, which can be configurable by
the bank based on the Bank’s practice or local regulation.
Camt Index Description User Configurable
Group Header
1.1 Message Identification Y
1.2 CreationDateTime
Statement
2.1 Identification Y
2.4 CreationDateTime
1.2.1 Account>ID>IBAN
1.2.2 Account>ID>OtherId Y
2.24 Balance>Type>Code
2.34 Balance>Amount
2.35 Balance>CreditDebitIndicator
2.36 Balance>Date
2.78 Entry>Amount
2.79 Entry>CreditDebit Indicator
2.81 Entry>Status
2.91 Entry>Bank Transaction Code>Proprietary Y
2.99 Entry>Issuer Y
Optional Tags Supported

Some optional tags are required under the NVB usage rules to report additional SEPA details.

The following table shows the list of high level optional tags that are supported by T24 with an indication of the tags that are required to report
SEPA details and the tags that may be configured by the bank based on the bank’s practice or local regulation.
Camt Index Description Usage rule under User configurable

NVB for report-
ing SEPA.
Required: 'Y'
Group Header
1.4 Message Pagination
Statement
2.2 ElectronicSequenceNumber Y
1.2.11,1.2.12,1.2.13 Account>Currency/Name/Owner
2.31 Balance>Credit Line
2.43 Transaction Summary
2.77 Entry>Entry Reference
2.8 Entry>Reversal Indicator Y
2.82 Entry>Booking Date Y
2.83 Entry>Value Date Y
2.84 Entry>Account Servicer Reference Y Y
2.3.14 Entry>Additional Entry Information Y Y
2.3.15 Entry>Additional Statement Information Y Y
2.143 Transaction Details>References Y
2.199 Transaction Details>Related Parties Y
2.211 Transaction Details>Related Agents Y
2.224 Transaction Details>Purpose Y
2.227 Transaction Details>Remittance Information Y
2.293 Transaction Details>Return Information Y
2.3.13 Transaction Details>Ad- Y Y

ditionalTransactionInformation
SEPA Details in CAMT Messages

The Camt message supports the SEPA details from transactions originating from an external SEPA system provided the entries from these
transactions are passed to T24.
The EXTERNAL.SEPA.DETAILS application is built to record and capture the SEPA details for each entry (STMT.ENTRY) generated from a
SEPA related transaction originating from an external SEPA system.
The EXTERNAL.SEPA.DETAILS can be input manually or through a local interface using OFS.
The link between the STMT.ENTRY and the External.SEPA.DETAILS table has to be built locally; it may be through any field from
STMT.ENTRY or Account tables, provided it is unique.
When processing each entry, the statement processor needs to access the corresponding EXTERNAL.SEPA.DETAILS record.

The EXT.SEPA.LINK.API field is available in AC.STMT.PARAMETER to provide a hook for a user defined logic to get the link between the
entry and the EXTERNAL.SEPA.DETAILS table.
The process of assembling data for the Camt message (as part of the Statement processor) is responsible to retrieve the SEPA details from the
EXTERNAL.SEPA.DETAILS table.
Additional tags are supported in XML.TAG.DEFINITION to hold the SEPA details from an External SEPA system.
Module Components
The T24 CAMT Module includes the following T24 applications:
l AC.STMT.PARAMETER
l ACCOUNT.STATEMENT
l XML.TAG.DEFINITION
l IX.EXTERNAL.CODES
l IX.DOMAIN.CODES
l IX.TRANSACTION
l XML.OUTPUT.MSG
l AC.XML.STMT.DATA
l AC.XML.STMT.EXCEPTION
l AC.XML.INTERIM.STMT.HIST
l AC.XML.INTRMSTMT.GENERATE
l XML.TRANSFORMATION
l EXTERNAL.SEPA.DETAILS
AC.STMT.PARAMETER
The purpose of this table is to define the default details for an account statement when opening new accounts. It also holds the high level para-
meter that is applicable to Account statement at the System level.
The AC.STMT.PARAMETER can be used to also to define the following:
l Provide the link between an entry to the EXTERNAL.SEPA.DETAILS table, which would hold the SEPA details from an external SEPA
system.
l Provide a hook routine to plug in APIs to filter and consolidate the list of entries for a specific Camt message.
Link Between the Entry and the EXTERNAL.SEPA.DETAILS Table
In order to identify the corresponding EXTERNAL.SEPA.DETAILS record that holds the SEPA details for a STMT.Entry, a link is required
between the STMT.Entry and the EXTERNAL.SEPA.DETAILS record.
As each implementation may have its own way of linking the STMT.ENTRY record to the EXTERNAL.SEPA.DETAILS, a hook is available to
attach a local API with the logic for the link. The API will return the key to the EXTERNAL.SEPA.DETAILS table.
The field EXT.SEPA.LINK.API in AC.STMT.PARAMETER is the hook that will get the link from the entry to the EXTERNAL.SEPA.DETAILS
table. It is a valid key to EB.API to hold the API that will return the link key to the EXTERNAL.SEPA.DETAILS table.
Hook for APIs to Filter and Consolidate Entries for a Specific Camt Message
Different variations of the Camt054 message can be generated by filtering the list of entries to be reported. A filter API can be invoked that will
be able to exclude entry detail based on whatever criteria are required by the bank.
Entries for the statement or report period can be combined into consolidated entries for the statement. The criteria and consolidation method
used may be determined by message types and decisions can be made through an API routine. This will consolidate entries together according
to the required rules and ensure that the consolidated entry is shown in the statement.
The following diagram shows the hook in AC.STMT.PARAMETER to plug in an API to return the link between the entry and the

ACCOUNT.STATEMENT
The Camt account statements and reports are generated using the standard Account statement functionality.
The purpose of the ACCOUNT.STATEMENT table is to specify the dates and frequencies for producing Account statements. A record is auto-
matically created with the default settings when an Account is set-up. It can then be defined specifically for each account, based on the cus-
tomer’s requirements. It is possible to define up to nine statement cycles, and within each cycle it possible to generate a combination of
different types of messages.
The field SWIFT.STMT.TYPE in the ACCOUNT.STATEMENT application is used to request a Camt or MT type message type for the first
cycle for an account.
The field SWIFT.STMT2.TYPE is used to define the message types for the additional statement cycles.
The following screenshot shows the set-up for CAMT and MT type messages for two statement cycles:

XML.TAG.DEFINITION
Local regulation and practice may specify the use of specific fields and the content of the optional fields are dependent on the business trans-
action that generated the entry. T24 supports a list of Optional tags and defaults the details based on the data available in T24.
The XML.TAG.DEFINITION allows the user to overwrite the information provided by T24 for tags that are flagged as User Configurable and to
suppress any Optional tag currently supported by T24.
It is possible to configure an individual data tag or a tag group. (More detail is provided under the section “Configuring the content of the Camt
message”.
Individual Data Tag

Each of the data tags is released as an empty record in the XML.TAG.DEFINITION table and is available to the user to modify. (Please refer to
‘Records released in XML.TAG.DEFINITION’ for the list of tags released).
The following shows an example of how the T24 data tag Account.ServFinInstOtherId (Account>Servicer>FinInstID>Other>Id) can be defined
as a fixed value.

Tag Group
A tag group is the parent of a list of child tags; the tag group can be configured, and it will apply to all the underlying child tags. A list of group
tags have been released (Refer to ‘Records released in XML.TAG.DEFINITION’ for the list of tags released).
The following shows the screen to configure a tag group, and a list of the child data tags falling under the group tag:
IX.EXTERNAL.CODES, IX.DOMAIN.CODES and IX.TRANSACTION

In T24, the transaction code is defined in the TRANSACTION table, and the STMT.ENTRY holds the field Transaction.Code to fully identify
the type of underlying transaction resulting in an entry.
The BankTransactionCode in ISO20022 consists of two main elements as given below:
l Domain (this uses the set of External codes as set by ISO20022)

l Proprietary (this can be defined by the Bank; by default, T24 is providing the field SWIFT.NARRATIVE from the TRANSACTION table
for the corresponding Transaction.Code from the entry.
In order to define the Domain Transaction code to be defined, the following tables are available to define the codes:

l IX.EXTERNAL.CODES to define the External codes as set by ISO20022.The only codes allowed are Domain, Family and Subfamily.
More External codes will be allowed in the future.
The following is an example to show a small list of External codes; the full list can be defined by the user.
l IX.DOMAIN.CODES to define the possible Domain Codes and the corresponding family and Subfamily Codes.
The following shows an example of how the Domain Code for ‘PMNT’ may be defined with a combination of Family and Sub Family codes. This
can be defined by the user.
l IX.TRANSACTION to define the possible Domain Codes and the corresponding Family and Subfamily Codes for the Application and
Transaction Code.
The following local fields must be created in IX.TRANSACTION to enable assigning a transaction type to a transaction code. This will be used
to plug in a hook routine in order to get the details for a tag group based on the transaction type (Refer to the section ’Configuring content of
group tag’):
l TXN.TYPE: to assign a specific Transaction type

l TXN.TYPE.RTN: If a locally defined logic is plugged in to assign a transaction type

XML.OUTPUT.MSG
The table XML.OUTPUT.MSG holds the actual Camt xml message output to the delivery channels. The key to the table consists of the xml
message type-unique Id – company Id of the account for which, the Camt message has been generated.
The following example shows a record in XML.OUTPUT.MSG, which consists of:
l Message date: the Statement date

l Message: the actual Camt xml message
l Account Number: The account number for which the XML message is generated
l Customer: The customer ID of the account owner
l The Statement cycle number
l The Recipient details
l The link to the AC.XML.STMT.DATA table, which contains basic details of the Account statement
The following shows an extract of a Camt053 xml message:
The following shows an extract of a camt054 xml message:

AC.XML.STMT.DATA
The ‘Live’ table AC.XML.STMT.DATA holds the basic details for the Camt statement being processed. The key to the table is the Accoun-
tNumber-Statement date.Statement Cycle.CompanyCode.Xml Message type. It also holds the details of the recipients of the Camt message.
The following shows the record for a Camt054 message with the recipients of the message.

AC.XML.STMT.EXCEPTION
This ‘Live’ table holds the details for unsuccessful Camt xml message(s); it provides the reasons for the message failure and it is possible to
resubmit a failed message for which the T24 xml format has been produced (Refer to section ‘Exception Handling for Camt messages’ for more
details).
The following example shows the exception record for a failed Camt052 message, for which, the xml Camt production has failed.
AC.XML.INTERIM.STMT.HIST

The purpose of the table is to hold the details of an intra- day Camt052 account report generated upon a request from the
DE.STATEMENT.REQUEST application (Refer to the section ‘Request and Trigger of a CAMT052 Intra-day account report’ for more details
on generation of a Camt052 message). The key to the table is the Account.Number-Statement date–Time statement that has been generated. It
contains the link to the XML.OUTPUT.MSG table and the number of entries contained in the intra-day account report.
The following example shows the details of a Camt052 generated for an account with the link to the XML.OUTPUT.MSG and the number of
entries in the statement.
AC.XML.INTRMSTMT.GENERATE
This is the service that will trigger the creation of the DE.STATEMENT.REQUEST records for a Camt052, if the intra-day report is requested
based on a set time during the day.
The following screenshot shows the TSA.SERVICE record released in T24.
XML.TRANSFORMATION
This is the service that is responsible for the actual Camt xml production. It will also update the AC.XML.STMT.EXCEPTION for a failed mes-
sage and the XML.OUTPUT.MSG for a successful Camt message production.
EXTERNAL.SEPA.DETAILS
The EXTERNAL.SEPA.DETAILS application can record the SEPA details from each entry generated from an External SEPA Module.
If the entry is a batched entry, the Batch details if any, will occur only once in the record. However, if the batch entry has multiple transactions,
then the associated fields (REF.MSG.ID to ADD.TXN.INFO) will be multi-valued for each transaction details from the batch entry.
The following screenshot shows an example of the EXTERNAL.SEPA.DETAILS record:

In order to identify the corresponding EXTERNAL.SEPA.DETAILS record that holds the SEPA details for a STMT.Entry, a link is required
between the STMT.ENTRY and the EXTERNAL.SEPA.DETAILS.
The following shows an example of the link between the STMT.ENTRY and the corresponding EXTERNAL.SEPA.DETAILS:

In the above example, the link between the STMT.ENTRY and the EXTERNAL.SEPA.DETAILS is through the field Narrative from
STMT.ENTRY, based on the following:
l The local accounting interface must update the NARRATIVE field in STMT.ENTRY with the key to link the
EXTERNAL.SEPA.DETAILS record with the STMT.ENTRY.
l At each implementation, an identifiable key can be decided and updated in the NARRATIVE field, through the local accounting inter-
face.
l A new local API (Refer to the field EXT.SEPA.LINK.API in AC.STMT.PARAMETER) will be called from the Statement Processing
routine, which will get the NARRATIVE details from the entry as the input data and return the unique key identifier to read the
l This local API can be written to identify that key and pass it back to the statement processor. The core statement processing will
simply read the EXTERNAL.SEPA.DETAILS table with that returned key.
l The API is mandatory to include the SEPA details from an External SEPA system and should be done locally because the NARRATIVE
is a multi-value field and can contain data that needs to go into the statement description for that entry.

Camt Generation Process
The Camt statements and reports are generated using the standard Account statement functionality. The request for the account statement and
report is defined in the ACCOUNT.STATEMENT table. Two variations of the Camt054 can be defined as CAMT054A and CAMT054.
Request and Trigger of a Camt053 and Camt054 Statement

It is possible to request a periodic Camt053 or Camt054 statement for an Account by setting the new field SWIFT.STMT.TYPE with the value
CAMT053 in the table ACCOUNT.STATEMENT
The following screenshot shows the request set-up for a Camt053 statement for an account under the field, SWIFT.STMT.TYPE:
The frequency of the Camt message follows the scheduled frequency for the Account statement. So if both MT940 and Camt053 are requested
for an account, the same frequency is applied to both statements.
The Camt053 and Camt054 messages are triggered by the T24 close of business when the next statement date for the specified frequency is
due.
Request and Trigger of a Camt052 Intra-day Account Report

There are two options to generate a Camt052 intra-day report in T24:
l Ad hoc request from the account owner

l Automatically based on a set time
If multiple Camt052 intra-day reports are generated within the same day, the entries shown in one Account report are not shown in the next
Account report.
Note: An account may request both Camt052 and Camt053
Ad-hoc Generation of an Intra-day Account Report

The Camt052 can be triggered manually through the application DE.STATEMENT.REQUEST upon ad hoc request from the account owner.
The following shows a view of a DE.STATEMENT.REQUEST record where a Camt052 has been generated.
The DE.STATEMENT.REQUEST process will take care of assembling the data and triggering the Camt052 generation. Once the Camt xml mes-
sage is successfully generated, the link to the AC.XML.STMT.DATA is recorded in the field OUT.DELIVERY.REF

Automatic Generation of an Intra-day Account Report Based on a Specific Time
The Camt052 intra-day report can also be generated automatically based on a specific time defined in the field MESSAGE.TIME in the
ACCOUNT.STATEMENT record.
When the MESSAGE.TIME is defined for an account, the Account Number is recorded in a table XML.SENT.TIME keyed on the
MESSAGE.TIME.
The following example shows the request of a Camt052 based on specific time and the update to XML.SENT.TIME table.

The AC.XML.INTRMSTMT.GENERATE service must be run and it will pick up the account report(s) that need to run based on the time.
The service creates and authorises a DE.STATEMENT.REQUEST for each account report to be generated.
The following is a view of the DE.STATEMENT.REQUEST record created for the account report.
Assembling of Statement Content

The statement processor as part of the Close of Business process will generate the types of Statements (e.g. Camt054a, Camt053, MT940 Prin-
ted Statements) that need to be produced for the account as defined in the corresponding ACCOUNT.STATEMENT record.
For a Camt053, Camt054a, Camt054b, the statement processor is responsible to assemble the data necessary to produce a Camt message for
each statement triggered.
For a Camt052, the DE.STATEMENT.REQUEST application is responsible to assemble the data for the intra-day report.
The data required for Camt message is structured as follows:
l Details for tags under the GroupHeader, specific to the Message

l Details specific to the Statement
l Details related to the account for which, the statement is being produced
l Balance related details for the account
l Transaction Summary (summary of the entries shown in the statement)
l Entry (details of the movements shown in the statement)
l Transaction Details (Additional details to the Entry for SEPA and Non SEPA related transaction)
The data is assembled based on the defined T24 internal logic for each tag supported by T24.

For tags flagged as user configurable or optional, the statement processor will check for any set-up in the XML.TAG.DEFINITION. This may
hold a user defined data source for a tag or the requirement to suppress any optional tag. (Please refer to the section “User Definable Tags for
Camt messages for more details).
Accounting Entries that are recorded in the STMT.ENTRY table of T24 form the basis of movements to be reported in the Account Statement.
The statement processor goes through the list of entry IDs required for the account statement recorded in the STMT.PRINTED or
STMT2.PRINTED table.
An additional check is made for each entry to identify if the entry originates from a SEPA related transaction.
If the SEPA related entry originates from an external SEPA system, then the API defined under the field EXT.SEPA.LINK is executed to get the
key to the EXTERNAL.SEPA.DETAILS. (Please refer to the section on EXTERNAL.SEPA.DETAILS under Module Components for more
details).
Transformation of Data
The assembled data is passed to the component service to produce a T24 xml format of the Camt message based on the T24 Camt schema.
The T24 xml format is recorded in the AC.XML.STMT.DATA table.
The bank middleware can take the published T24 Camt schema and transform the content to the published ISO20022 schema. At this stage, it
is possible to perform further enrichment of the data with other external data sources.
Temenos has provided a standard transformation (XSLT) of the T24 schema to ISO20022 Camt schema.
Camt XML Message Production

A transformation service XML.TRANSFORMATION is responsible to process the T24 xml messages and transform them into a fully formatted
xml Camt message as per ISO20022 published schema.
The xml Camt messages may be sent through different channels based on customer preferences for receiving such a message. This needs to be
done by the system in use for routing messages at the bank.
Record XML Camt Message

The actual xml Camt message is recorded in the XML.OUTPUT.MSG table for audit purpose as shown below:

View an XML Camt Message
In order to view the CAMT message for an account, a link is available between the account and the XML.OUPUT.MSG table through the field
DELIVERY.REF, in the ACCOUNT.STATEMENT record. The field DELIVERY.REF holds the key to the XML.OUTPUT.MSG for Camt mes-
sage and the key to DE.O.HANDOFF for a Swift statement.
The ACCOUNT.STATEMENT record shows an account for which, both a Swift statement and a Camt message have been generated.

The following shows the structure of an xml view of a Camt message:

Generation of a Camt Message to Multiple Recipients
A Camt messages is sent to the account owner and it may also be sent to a third party authorised by the account owner to receive the message.
Upon request from the account owner, a copy of the Camt message may be sent to multiple recipients.
Setting up Multiple Recipients for a Camt Message

The recipients of a Camt message can be defined using the Carrier functionality within T24. The Carrier used for the Camt messages is
‘ISOREPORT’
Addresses for different recipients are defined in the T24 application DE.ADDRESS. For Camt statements, it is possible to provide the correct
identifier for the customer as the destination (carrier) for the Camt message without having to define additional customer records for T24.
T24 uses the applications DE.CUSTOMER.PREFERENCES and DE.PRODUCT to define the recipients of a particular message.
In the case of account statements, it is possible to specify the recipient for a particular statement cycle as well as message type. This func-
tionality allows multiple recipients to be specified based on the type of message and cycle for all types of statements.
The DE.PRODUCT application is also used to define any additional recipient (s) for the Camt message using the identifier or customer record
other than the account owner. This is possible by using the field MDR.CUSTOMER for the ‘ISOREPORT’ carrier.
The following shows how an additional recipient is added in the DE.PRODUCT record for the Camt message under the ‘ISOREPORT’ carrier
using the account owner’s customer identifier and also using the customer identifier of another customer.

Camt Message for Multiple Recipients
When the Camt message is generated, a copy of the same message is sent to the additional recipient. The tags Message recipient and
CopyDuplicateIndicator are enriched to indicate the copy of the message sent to a recipient other than the account owner.
The following shows the same Camt message sent to multiple recipients, the account owner and a third party as defined under the
MDR.CUSTOMER field.
The Camt053 message is sent to the account owner:

A copy of the same message sent to a third party where the tags Message recipient and CopyDuplicateIndicator are enriched:

Exception Handling of CAMT Messages
Recording a Failed Camt Message

The transformation process updates an Exception table AC.XML.STMT.EXCEPTION for the messages that have failed.
The table AC.XML.STMT.EXCEPTION provides enough details for the user to understand the reason why the Camt message has failed shown
under the field ERROR.SOURCE:
l “Data.Assembly”: The Statement data is not correct, e.g. mandatory field may be missing data. Hence the T24 xml cannot be produced.
l “Integration”: Problem during the transformation process; the T24 xml cannot be produced.
l “Xml.Transform”: Problem during the Camt production; the T24 xml has been produced but the corresponding XML Camt message
cannot be produced.
For failed messages due to missing data for mandatory tags, additional information is provided for the tag(s) for which, data is missing.
It is possible to view the list of failed messages from AC.XML.STMT.EXCEPTION through the Enquiry XML.EXCEPTION.MESSAGE.
The following shows an example of a failed Camt message for which, the T24 xml has been produced but failed during the actual Camt message
production.
Resubmitting a Failed Camt Message

The first time a Camt message fails, the MESSAGE.STATUS will be set to “ERROR”.
It is possible to resubmit a failed message for which the T24 xml message has been produced, i.e. only when the field ERROR.SOURCE in
AC.XML.STMT.EXCEPTION is set to ‘XML.TRANSFORM’.
Therefore it is not possible to resubmit a message if it has failed because of the missing mandatory tag as the T24 xml format will not be pro-
duced.

It is possible to view a list of Camt messages that have failed, which can be resubmitted through the ENQUIRY
RESUBMIT.XML.EXCEPTION.
To resubmit a failed Camt message, the field MSG.RESUBMIT must be set to ‘YES’.
The following example shows a failed message being resubmitted:
After the record is authorised, the message will be set as ‘resubmitted’ to the Camt message production service, and the following will happen:
l The field MSG.RESUBMIT.DATE will be updated with today’s date.

l If the xml Camt production fails again, the MESSAGE.STATUS will still be set to ”ERROR”
l If the xml Camt xml production is successful, then the MESSAGE.STATUS will be set to ‘SUCCESS’
The following shows the resubmitted message for which the Camt xml production has been successful:

Archiving of XML Statement Related Tables
The T24 archiving mechanism supports the following XML Statement related tables:
l XML.OUTPUT.MSG
l AC.XML.STMT.DATA
l AC.XML.STMT.EXCEPTION
l EXTERNAL.SEPA.DETAILS
The following records have been released and may be modified to define the retention date on which older records will be archived from the live
table into an archived table($ARC). This can be set by either defining a specific purge date under the field PURGE.DATE or
RETENTION.PERIOD.
The record ARC.AC.XML.STMT is used to define the archiving period for AC.XML.STMT.DATA and AC.XML.STMT.EXCEPTION, the
records that will be archived will be all records from AC.XML.STMT.DATA and AC.XML.STMT.EXCEPTION with STMT.DATE less than the
PURGE.DATE defined in the record.
The record ARC.EXTERNAL.SEPA is used to define the retention period for the EXTERNAL.SEPA.DETAILS table. The records that will be
archived from EXTERNAL.SEPA.DETAILS are those with ENTRY.DATE less than six months.

The record ARC.XML.OUTPUT.MSG is used to define the retention period for the XML.OUTPUT.MSG table. The records that will archived
from XML.OUTPUT.MSG are those with MSG.DATE less than six months.
Configuring the Content of the Camt Message

To facilitate Banks to adhere to local regulation and practice, a flexible mechanism is available to configure the content of the Camt message,
with the following, using locally defined logic:

l Ability to filter the list of entries for a specific Camt message type
l Ability to consolidate a list of selected entries to be reported as one entry
l Ability to suppress a data tag or a group of data tags
l Ability to configure the content of a data tag or a group of data tags
Filtering Entry Content
This field FILTER.RTN in AC.STMT.PARAMETER provides the capability to allow the entry list for the report cycle to be filtered. A filter API
can be invoked by the statement processor that will be able to exclude entry detail based on whatever criteria are required by the bank. This
will allow the inclusion and exclusion of information based on the recipient receiving the report. It may be typically used to restrict the list of
entries reported under Camt054 (Debit/Credit Notification).
The API will be passed at the entry, and it will have to return a flag to indicate if the entry can be included in the account report. A test API,
IX.FILTER.ROUTINE has been released as an example of how the API should be built.
The following shows the set-up to plug-in an API to filter the entries for Camt054 account report:
Consolidation of Selected Entries
Entries for the period under consideration can be combined into consolidated entries for the statement. The criteria and consolidation method
used, will be able to be determined by message type and the decision will be made through an API routine. The field CONSOLIDATE.RTN in
AC.STMT.PARAMETER provides the hook to plug in the API. This will consolidate entries together according to the required rules and ensure
that the consolidated entry is shown in the statement.
The default consolidation grouping will be using the following elements from the entry:
l System Id
l Transaction Code
l Booking Date
l Reversal Marker
The API will be passed at the entry and the consolidation group. The API may alter or clear the consolidation group. It may also change the
Transaction code, if a specific transaction code is preferred for a consolidated entry. This will allow showing a specific transaction description
in the Camt message.
Whilst the statement will show the consolidated entry in the statement but the actual entries are held in detail in the system. This will be typ-
ically used when an account report has been generated for a selected list of entries with all the details, but in the statement, the entries may be
reported as one consolidated entry. A test API, IX.CONSOLIDATE.RTN has been released as an example of how the API should be built.
The following shows how an API may be plugged in to consolidate entries for a Camt053 account statement:

Suppressing Information
The application XML.TAG.DEFINITION will allow an individual tag or group of tags defined as ‘Optional’ under Camt, to be suppressed for a
specific message type or entry from a specific application. Additionally, it will be possible to make more complex suppression decisions
through a developed API routine to handle specific Banks criteria.
The following shows the suppression set-up for a group tag for Batch details. The suppression can be set by default for the group, or by mes-
sage type as shown here, or under the application or transaction type for the message type. The following shows the suppression for Camt053
by setting the suppress flag as ‘Yes’ and for Camt054a, the suppression is based on a logic defined in the API ‘SUPP.BATCH.DTLS’.
The following shows how the suppression set-up for a data tag can be defined:
Configuring the Content of Data Tags
The content of a tag group or individual data tags may be required to meet local regulation or Banks’ requirements.

A mechanism is available to configure either a group tag or an individual data tag.
Tag group
The following tag groups are available in XML.TAG.DEFINITION to configure the data tags associated with the group instead of each indi-
vidual data tag.
Group.Tag Child.Group Child Tag
Header.Recipient.Details <Header.MsgRecpName>
<Header.MsgRecpPAddCtry>
<Header.MsgRecpAddLine>
<Header.MsgRecpIdOrgIdBIC>
<Header.MsgRecpOrgIdOtherId>
<Header.MsgPgnPgNbr>
<Header.MsgPgnLstPgInd>
Balance.Details Balance.Amt.Details <Balance.TypeCode
<Balance.CcyAmount>
<Balance.CrdtDbtInd>
<Balance.Date>
Balance.CredLine.Details <Balance.CredLineIncl>
<Balance.CredLineAmount>
Entry.Details Batch.Details <EntryDetails.BtchMsgId>
<EntryDetails.BtchPmtInfoId>
<EntryDetails.BtchNbOfTxns>
<EntryDetails.BtchTtlAmt>
<EntryDetails.BtchCrdtDbtInd>
Transaction.Details All Txn.Det tags
The tag groups Balance.Details and Entry.Details have underlying child groups, which in turn have a list of associated data tags.
Suppression of Tag Group
The following figure shows an example of tag group Entry.Details and the associated child.groups along with Batch.Details and Transaction
Detail; each child group has its associated data tags. The Tag group Entry.details is not suppressed, so the Camt processor will then check for
the Child group.
The example shows that the child group Batch.Details is always suppressed for Camt053 by setting the Msg.Suppress field to ‘Yes’, while for
Camt054a, a local API has been plugged in to apply a locally defined logic to decide if tag groups must be suppressed.

Configuring Content of Group Tag
If details are required, then the detailed content for the associated message tags for the entry can be built through API provided by the T24
Camt product. Temenos will release standard APIs for standard payments transactions, but local development can be performed to provide
information required for local payment types and bank specific requirement.
The following example shows how an API can be plugged in for different FT transaction types for a Camt message (Camt053), and how it is
also possible to define a transaction type using a locally defined logic and plugging in an API for different transaction types:
Note: The fields Txn.Type and Txn.Type.Rtn must be created as local fields in order to have the ability to assign a transaction type in the
IX,TRANSACTION table.
A local API is plugged in local fields namely TXN.TYPE.RTN in IX.TRANSACTION in order to return the following possible transaction types
based on a locally defined logic.

l Blank: This is the default where there is no specific transaction type. Here it will use the System ID from the Entry, i.e. FT and a stand-
ard API will be released to get the transaction details for a standard FT.
l FOREIGN”; The local requirement can define a transaction type for foreign payment and a local API to get the details for this trans-
action type.
The example also shows that the transaction type ‘SEPA’ is assigned to transaction code ‘213’ in IX,TRANSACTION and also the API in order
to get the SEPA details that is plugged in, under transaction type FT*SEPA
Individual Data Tag
The following screen shows the set-up in XML.TAG.DEFINITION for a tag flagged as user configurable. The example shows that the user has
set a fixed value for the tag.
The field DATA.SOURCE defines the source from where the data for the User configurable tag will be retrieved from. There can be three pos-
sible ways of how data can be retrieved for the tag:
l VALUE – Data of the tag is a fixed value

l API – Data of the tag will be retrieved through an API
l TABLE – Data of the tag is directly linked to a T24 table.
The field SOURCE.VALUE field is used for the corresponding value when the DATA.SOURCE is set to “VALUE” or “API”.
The field SOURCE.TABLE is used to hold the T24 table from which data will be retrieved. It is mandatory, if the field DATA.SOURCE is set as
TABLE.
The field SOURCE.LINK is used to establish the link between the STMT.ENTRY record to the T24 table defined in SOURCE.TABLE and it will
be a valid field from the Standard Selection.
The field SOURCE.FIELD is use to define the field from the the T24 table defined in SOURCE.TABLE, which is the data source for the tag.

The field SUPPRESS.TAG is set to “Yes” if an optional tag needs to be suppressed from the Camt message. This is allowed only for the
Optional tags and is not possible to suppress the display of a Mandatory tag.
Records Released in XML.TAG.DEFINITION

The following table shows the list of data tags released in the XML.TAG.DEFINITION table available for the user to configure.
User Configurable Tags

The list of supported tags flagged as User configurable for which the User may overwrite the logic:
Index T24 naming convention Tag Description User Man-

Con- datory
fig- /Op-
urable tional
Header
1.1 <Header.MsgId> Group.Header.Message Identification Y M
1.2 <Header.Credtime> Group.Header.CreationDateTime M
1.5 <Header.AddInfo> Group.Header.Additional Info Y O
9.1.0 <Header.MsgRecpName> Message recipient>Name O
9.1.10 <Header.MsgRecpPAddCtry> Message recipient>PostalAddress>Country O
9.1.11 <Header.MsgRecpAddLine> Message recipient>PostalAddress>AddressLine O
9.1.14 <Header.MsgRecpIdOrgIdBIC> Message recipient>Identification>OrgId>BIC or BEI O
9.1.16 <Header.MsgRecpOrgIdOtherId> Message recipient>Identification>OrgId>Other>Id Y O
8.1.0 <Header.MsgPgnPgNbr> Message Pagination>Page Number O
8.1.1 <Header.MsgPgnLstPgInd> MessagePagination>LastPageIndicator O
Statement/Notification
2.1 <Statement.Id>/Notificaton Id Statement>Identification Y M
2.2 <Statement.ElecSeqNumber> Statement>ElectronicSequenceNumber Y O
<Statement.LegalSeqNumber> Legal Sequence Number Y O
2.4 <Stmt.CredDtTime> M
5.1.0 <Stmt.FrToDtFrmDate> From date ToDate From Date Y O
5.1.1 <Stmt.FrToDtFrmDate> From date ToDate To Date Y O
2.6 <Statement.CopyDupInd> CopyDuplicateIndicator O
2.3.15 <Statement.Addstmtinf> Additional Statement Information Y
Account
1.2.1 <Account.IdIBAN> Account>Identification>IBAN M
1.2.3 <Account.IdOtherId> Account>Identification>Other>Identification M
1.1.9 <AccountTypeCd> Account>Type>Code Y O

1.2.11 <Account.Ccy Account>Currency O
1.2.12 <Account.Name> Account>Name O
1.2.14 <Account.OwnName> Account>Owner>Name O
1.2.21 <Account.OwnPstlAdrPstCd> Account>Owner>PostalAddress>PostCode O
1.2.22 <Account.OwnPstlAdrTwnNme> Account>Owner>PostalAddress>TownName O
1.2.24 <Account.OwnPstlAdrCtry> Account>Owner>PostalAddress>Country O
1.2.25 <Account.OwnAddrLine> Account>Owner>PostalAddress>AddressLine O
1.2.58 <Account.ServFinInstBIC> Account>Servicer>FinInstID>BIC> O
1.2.77 <Account.ServFinInstOtherId> Account>Servicer>FinInstID>Other>Id Y O
Balance
2.26 <Balance.TypeCode Balance>Type>CodeorProprietary>Code M
2.32 <Balance.CredLineIncl> Balance>CreditLine>Included O
2.33 <Balance.CredLineAmount> Balance>Creditline>Amount O
2.34 <Balance.CcyAmount> Balance>Amount M
2.35 <Balance.CrdtDbtInd> Balance>CreditDebit Indicator M
2.36 <Balance.Date> Balance>Date M

(4.1.0)
Transaction Summary
2.45 <TxnSummTotEntNbOfEntries> Transaction Summary>NumberofEntries O
2.46 <TxnSumm.TotEntSum> Transaction Summary>Sum O
2.47 <TxnSum- Transaction Summary>TotalNetEntryAmount O

m.TotEntNetEntAmount>
2.48 <TxnSumm.TotEntCrdtDbtInd > TransactionSummary>CreditDebitIndicator O
2.50 <TxnSum- TransactionSummary>TotlCreditEntries>NoofEntries O

mTotCrEntNbOfEntries>
2.51 <TxnSummTotCrEntSum> TransactionSummary>TotlCreditEntries>Sum O
2.53 <TxnSum- TransactionSummary>TotlDebitEntries>NoofEntries O

mTotDrEntNbOfEntries>
2.54 <TxnSummTotDrEntSum> TransactionSummary>TotlDebitEntries>Sum O
Entry
2.78 <Entry.CcyAmount> Entry>Amount M
2.79 <Entry.CrdtDbtInd> Entry>CreditDebitIndicator M
2.81 <Entry.Status> Entry>Status M
2.93 <Entry.BkTxDomain> (Either) Entry>BankTransactionCode>Domain>Code O
2.95 <Entry.BkTxFamilyCd Entry>BankTransactionCode>Domain>Family>Code O

2.96 <Entry.BkTxSubFamilyCd Entry>BankTransactionCode>Domain>Family>SubfamilyCode O
2.98 <Entry.BkTxPrtryCode> (Or) Entry>BankTransactionCode>Proprietary>Code Y M
2.99 <EntryEntry.BkTxPrtryIssuer> Entry>BankTransactionCode>Proprietary>Issuer Y M
2.77 <Entry.EntryRef> Entry>EntryReference O
2.8 <Entry.RevInd> Entry>ReversalIndicator O
2.82 <Entry.BookDate> Entry>BookDate O
2.83 <Entry.ValueDate> Entry>ValueDate O
2.84 <Entry.AcctSvcrRef> Entry>AccountServicerReference Y O
2.314 <Entry.AddEntryInfo> Entry>AdditionalEntryInformation Y O
Entry Details>Batch Details
2.137 <EntryDetails.BtchMsgId> Batch>MessageIdentification O
2.138 <EntryDetails.BtchPmtInfoId> Batch>PaymentInformationId O
2.139 <EntryDetails.BtchNbOfTxns> Batch>NumberOfTransactions O
2.14 <EntryDetails.BtchTtlAmt> Batch>Total Amount O
2.141 <EntryDetails.BtchCrdtDbtInd> Batch>CreditDebit Indicator O
Entry Details>Transaction Details
2.144 <TxnDet.RefMsgId> Transaction Details>References>MsgId O
2.145 <TxnDet.RefAcctServref> Transaction Details>References>AccountServicerref Y O
2.146 <TxnDet.RefPmtinfid> Transaction Details>References>PaymentInformationId O
2.147 <TxnDet.RefInstid> Transaction Details>References>InstuctionId O
2.148 <TxnDet.RefEndtoendid> Transaction Details>References>EndtoEndOd O
2.149 <TxnDet.RefTranId> Transaction Details>References>TransactionId O
2.150 <TxnDet.RefMandtid> Transaction Details>References>MandateId O
2.151 <TxnDet.RefChqNbr> Transaction Details>References>ChequeNumber O
2.154 <TxnDet.RefPrtyTyp> Transaction Details>References>Proprietary>Type Y O
2.155 <TxnDet.RefPrtyRef> TransactionDetails>References>Proprietary>Reference O
Entry Details>Transaction Details>AmountDetails
2.104>- TxnDet.InstrdAmt Transaction Details>AmountDetails>Instructed Amount>Amount Y O

2.1.1
2.1.10 <TxnDet.Txnamt> Transaction Details>AmountDetails>TransactionAmount>Amount Y O
2.1.12 <TxnDet.CcyXchgSrcCcy> Transaction Details>AmountDetails>TransactionAmount>Currency

Exchange>Source Currency
2.1.13 <TxnDet.CcyXchgTgtCcy> Transaction Details>Amount Details>Transaction Amount>Currency Y O

Exchange>Target Currency

2.1.14 <TxnDet.CcyXchgUntCcy> Transaction Details>Amount Details>Transaction Amount>Currency Y O
Exchange>Unit Currency
2.1.15 <TxnDet.CcyXchgRate> Transaction Details>Amount Details>Transaction Amount>Currency Y O

Exchange>Exchange Rate
2.1.16 <TxnDet.CcyXchgContId> Transaction Details>Amount Details>Transaction Amount>Currency Y O

Exchange>Contract Identification
2.1.36 <TxnDet.PrtryAmt> Transaction Details>Amount Details>Instructed Amount>Prorprietary Y O

Amount
2.165 <TxnDet.BkTranDomain> Transaction Details>Bank Transaction Code>Domain>Code O
<TxnDet.BkTranFamilyCd> O
<TxnDet.BkTranSubFamilyCd> O
2.170 <TxnDet.Txncode> Transaction Details>Bank Transaction Code>Proprietory>Code Y O
2.1.71 <TxnDet.Issuer> Transaction Details>Bank Transaction Code>Proprietory>Issuer Y O
Debtor
9.1.0 <TxnDet.RelDebtrName> Transaction Details>RelatedParties>Debtor>Name Y O
9.1.10 <TxnDet.RelDebtrAddCtry> Transaction Details>RelatedParties>Debtor>PostalAddress>Country O
9.1.11 <TxnDet.RelDebtrAddLine> Transaction Details>RelatedParties>Debt- O

or>PostalAddress>AddressLine
9.1.14 <TxnDet.RelDebtrIdOrgIdBIC> Transaction Details>RelatedParties>Debtor>Identification>OrgId>BIC O

or BEI
9.1.16 <TxnDet.RelDebtrIdOr- O
gIdOtherId>
9.1.18 <TxnDet.RelDebtrIdOr- Transaction Details>RelatedParties>Debt- O

gIdOthrIdScCd> or>Identification>OrgId>Other>SchemeName>Code

gIdOthrIdScPrtry> or>Identification>OrgId>Other>SchemeName>Proprietary

gIdOthrIdIssuer> or>Identification>OrgId>Other>Issuer
9.1.23 <TxnDet.RelDebtrIdPr- Transaction Details>RelatedParties>Debt- O

vtDpobBrthDt> or>Identification>PrivateId>DateAndPlaceOfBirth>Birthdate

vtDpobPrvBrth> or>Identification>PrivateId>DateAndPlaceOfBirth>ProvinceOfBirth

vtDpobCityBrth> or>Identification>PrivateId>DateAndPlaceOfBirth>CityBirth
9.1.26 TxnDet.RelDebtrIdPr- Transaction Details>RelatedParties>Debt- O

vtDpobCtryBrth> or>Identification>PrivateId>DateAndPlaceOfBirth>CountryOfBirth

vtIdOthrId> or>Identification>PrivateId>Other>Id

vtIdOthrIdSchNmCd> or>Identification>PrivateId>Other>SchemeName>Code

vtIdOthrIdSchNmPrtry> or>Identification>PrivateId>Other>SchemeName>Proprietary

vtIdOthrIdIssuer> or>Identification>PrivateId>Other>Issuer
9.1.33 <TxnDet.RelDebtrCtryOfRes- Transaction Details>RelatedParties>Debtor>CountryOfResidence O

idence>
1.1.1 <TxnDet.RelDetbrAcctIdIBAN> Transaction Details>RelatedParties>Debt- O

orAccount>Identification>IBAN
1.1.3 <TxnDet.RelDetbrAcctIdOthrId> Transaction Details>RelatedParties>Debt- O

orAccount>Identification>Other>Id
1.1.11 <TxnDet.RelDetbrAcctCcy> Transaction Details>RelatedParties>DebtorAccount>Currency O
Ultimate Debtor
9.1.0 <TxnDet.RelUltDebtrName> Transaction Details>RelatedParties>UltimateDebtor>Name O
9.1.10 <TxnDet.RelUltDebtrAddCtry> Transaction Details>RelatedParties>Ul- O

timateDebtor>PostalAddress>Country
9.1.11 <TxnDet.RelUltDebtrAddLine> Transaction Details>RelatedParties>Ul- O

timateDebtor>PostalAddress>AddressLine
9.1.14 <TxnDet.RelUltDebtrIdOr- Related Parties>Ultimate Debtor>Org ID>BIC/Other O

gIdBIC>
9.1.16 <TxnDet.RelUltDebtrIdOr- Transaction Details>RelatedParties>Ul- O

gIdOthrId> timateDebtor>Identification>OrgId>Other>Id

gIdOthrIdSchNmCd> timateDebtor>Identification>OrgId>Other>SchemeName>Code

gIdOthrIdSchNmPrtry> timateDebtor>Identification>OrgId>Other>SchemeName>Proprietary

gIdOthrIdIssuer> timateDebtor>Identification>OrgId>Other>Issuer
9.1.23 <TxnDet.RelUltDebtrIdPr- Transaction Details>RelatedParties>Ul- O

vtDpobBrthDt> timateDebtor>Identification>PrivateId>DateAndPlaceOfBirth>Birthdate
9.1.24 <TxnDet.RelUltDebtrIdPr- Transaction Details>RelatedParties>Ul-

vtDpobPrvBrth> tim-
ateDebtor>Identification>PrivateId>DateAndPlaceOfBirth>ProvinceOfBirth

vtDpobCityBrth> tim-
ateDebtor>Identification>PrivateId>DateAndPlaceOfBirth>CityOfBirth

vtDpobCtryBrth> tim-
ateDebtor>Identification>PrivateId>DateAndPlaceOfBirth>CountryOfBirth

vtIdOthrId> timateDebtor>Identification>PrivateId>Other>Id
9.1.30 <TxnDet.RelUltDebtrIdPr- O
vtIdOthrIdScCd>

vtIdOthrIdScPrtry>
vtIdOthrIdIssuer>
9.1.33 <TxnDet.RelUltDebtrCtryOfRes- O
idence>
Creditor
9.1.0 <TxnDet.RelCrdtrName> Transaction Details>RelatedParties>Creditor>Name O
9.1.10 <TxnDet.RelCrdtrAddLine> Transaction Details>RelatedParties>Cred- O

itor>PostalAddress>AddressLine
9.1.11 <TxnDet.RelCrdtrAddCtry> Transaction Details>RelatedParties>Creditor>PostalAddress>Country O
9.1.14 <TxnDet.RelCrdtrIdOrgIdBIC> Transaction Details>RelatedParties>Creditor>Identification>OrgId>BIC O

or BEI
9.1.16 <TxnDet.RelCrdtrIdOr- O
gIdOthrId>
9.1.18 <TxnDet.RelCrdtrIdOr- Transaction Details>RelatedParties>Cred- O

gIdOthrIdScCd> itor>Identification>OrgId>Other>SchemeName>Code

gIdOthrIdScPrtry> itor>Identification>OrgId>Other>SchemeName>Proprietary

gIdOthrIdIssuer> itor>Identification>OrgId>Other>Issuer
9.1.23 <TxnDet.RelCrdtrIdPr- Transaction Details>RelatedParties>Cred- O

vtDpobBrthDt> itor>Identification>PrivateId>DateAndPlaceOfBirth>Birthdate

vtDpobPrvBrth> itor>Identification>PrivateId>DateAndPlaceOfBirth>ProvinceOfBirth

vtDpobCityBrth> itor>Identification>PrivateId>DateAndPlaceOfBirth>CityOfBirth

vtDpobCtryBrth> itor>Identification>PrivateId>DateAndPlaceOfBirth>CountryOfBirth

vtIdOthrId> itor>Identification>PrivateId>Other>Id
9.1.30 <TxnDet.RelCrdtrIdPr- TransactionDetails>Related Parties>Creditor Accoun- O

vtIdOthrIdSchNmCd> t>Id>Other>Scheme Name>Code

vtIdOthrIdSchNmPrtry> itor>Identification>PrivateId>Other>SchemeName>Proprietary

vtIdOthrIdIssuer> itor>Identification>PrivateId>Other>Issuer
9.1.33 <TxnDet.RelCrdtrCtryOfRes- Transaction Details>RelatedParties>Creditor>CountryOfResidence O

idence>
1.1.1 <TxnDet.RelCrdtrAcctIdIBAN> Transaction Details>RelatedParties>CreditorAccount>Id>IBAN O
1.1.3 <TxnDet.RelCrdtrAcctIdOthrId> Transaction Details>RelatedParties>CreditorAccount>Id>Other>Id O

1.1.5 <TxnDet.RelCrdtrAcctIdO- Transaction Details>RelatedParties>CreditorAccount>Scheme Y O
thrSchNmCd> Name>Code
1.16 <TxnDet.RelCrdtrAcctIdO- Transaction Details>RelatedParties>CreditorAccount>Scheme Y O

thrSchNmPrtry> Name>Proprietary
1.1.11 <TxnDet.RelCrdtrAcctCcy> Transaction Details>RelatedParties>CreditorAccount>Currency O
Ultimate Creditor
9.1.0 <TxnDet.RelUltCrdtrName> Transaction Details>RelatedParties>UltimateCreditor>Name O
9.1.10 <TxnDet.RelUltCrdtrAddCtry> Transaction Details>RelatedParties>Ul- O

timateCreditor>PostalAddress>Country
9.1.11 <TxnDet.RelUltCrdtrAddLine> Transaction Details>RelatedParties>Ul- O

timateCreditor>PostalAddress>AddressLine
9.1.14 <TxnDet.RelUltCrdtrIdOr- Transaction Details>RelatedParties>Ul- O

gIdBIC> timateCreditor>Identification>OrgId>BIC or BEI

gIdOthrId> timateCreditor>Identification>OrgId>Other>Id

gIdOthrIdSchNmCd> timateCreditor>Identification>OrgId>Other>SchemeName>Code

gIdOthrIdSchNmPrtry> timateCreditor>Identification>OrgId>Other>SchemeName>Proprietary

gIdOthrIdIssuer> timateCreditor>Identification>OrgId>Other>Issuer
9.1.23 <TxnDet.RelUltCrdtrIdPr- Transaction Details>RelatedParties>Ul- O

vtDpobBrthDt> tim-
ateCreditor>Identification>PrivateId>DateAndPlaceOfBirth>Birthdate

vtDpobPrvBrth> tim-
ateCreditor>Identification>PrivateId>DateAndPlaceOfBirth>ProvinceOfBirth

vtDpobCityBrth> tim-
ateCreditor>Identification>PrivateId>DateAndPlaceOfBirth>CityOfBirth
9.1.26 TxnDet.RelUltCrdtrIdPr- Transaction Details>RelatedParties>Ul- O

vtDpobCtryBrth> tim-
ateCreditor>Identification>PrivateId>DateAndPlaceOfBirth>CountryOfBirth
9.128 <TxnDet.RelUltCrdtrIdPr- TransactionDetails>RelatedParties>Ultimate Cred- O

vIdOthrId> itor>Id>PrivateId>Other Id

vtIdOthrIdScCd> timateCreditor>Identification>PrivateId>Other>SchemeName>Code

vtIdOthrIdScPrtry> tim-
ateCreditor>Identification>PrivateId>Other>SchemeName>Proprietary

vtIdOthrIdIssuer> timateCreditor>Identification>PrivateId>Other>Issuer
9.1.33 <TxnDet.RelUltCrdtrCtryOfRes- Transaction Details>RelatedParties>Ul- O

idence> timateCreditor>CountryOfResidence

Debtor Agent
6.1.1 <TxnDet.DebtrAgtFinInsIdBIC> Transaction Details>RelatedA- O

gents>DebtorAgent>FinancialIdentification>BIC
6.1.2 <TxnDet.DebtrAgtCl- Transaction Details>RelatedA- O

gSysMIdClgSysCd> gent-
s>DebtorAgent>FinancialIdentification>ClearingSystemMemberId>Clearing
SystemId>Code
6.1.3 <TxnDet.DebtrAgtCl- Transaction Details>RelatedA- O

gSysMIdMmbId gent-
s>DebtorAgent>FinancialIdentification>ClearingSystemMemberId>MemberId
6.1.7 <TxnDet.DebtrAgtName> Transaction Details>RelatedA- O

gents>DebtorAgent>FinancialIdentification>Name
Creditor Agent
6.1.0 <TxnDet.CrdtrAgtFinInsIdBIC> Transaction Details>RelatedA- O

gents>CreditorAgent>FinancialIdentification>BIC
6.1.4 <TxnDet.CrdtrAgtCl- Transaction Details>RelatedA- O

gSysMIdClgSysCd> gent-
s>CreditorAgent>FinancialIdentification>ClearingSystemMemberId>Clearing
SystemId>Code
6.1.6 <TxnDet.CrdtrAgtCl- Transaction Details>RelatedA- O

gSysMIdMmbId gent-
s>CreditorAgent>FinancialIdentification>ClearingSystemMemberId>MemberId
6.1.7 <TxnDet.CrdtrAgtName> Transaction Details>RelatedA- O

gents>CreditorAgent>FinancialIdentification>Name
Purpose
2.225 <TxnDet.PurposeCode> Transaction Details>Purpose>Code O
2.226 <TxnDet.PurposeProp> Transaction Details>Purpose>Proprietary Y O
RelatedDates
2.267 TxnDet.RelDtsAccptDate> Transaction Details>Related Dates>AcceptanceDtTme Y O
Remittance Info
2.235 <TxnDet.RemInfoUnstruct> Transaction Details>RemittanceInfo>Unstructured O
2.240 <TxnDet.RemIn- Transaction Details>Remittance Info >Struc- Y O

foStructRefDocInfoTpCd> tured>ReferredDocumentationInformation>Type>Code orPro-
prietary>Code

foStructRefDocInfoNmbr> tured>ReferredDocumentationInformation>Number

foStructRefDocInfoRelDate> tured>REferredDocumentationInformation>RelatedDate

foStructRefDocAmtRemAmt> tured>ReferredDocumentationInformation>RemittedAmount
2.259 <TxnDet.RemIn- Transaction Details>Remit- Y O

foStructCrdtRefInfoTypCode> tanceIn-
fo>Structured>CreditorReferenceInfo>Type>CodeorProprietary>Code

foStructCrdtRefInfoTypPrtry> tanceIn-
fo>Structured>CreditorReferenceInfo>Type>CodeorProprietary>Proprietary

foStructCrdtRefInfoIssuer> tanceInfo>Structured>CreditorReferenceInfo>Type>Issuer

foStructCrdtRefInfoReference> tanceInfo>Structured>CreditorReferenceInfo>Reference
2.263>- <TxnDet.RemIn- Transaction Details>Remit- Y O

9.1.13 foStructInvcrIdOrgIdOthrId> tanceInfo>Structured>Invoicer>Id>OrgID>Other>Id
2.265 <TxnDet.RemIn- Transaction Details>RemittanceInfo>Structured>Additional Information Y O

foStructAddInfo>
Return Info
2.305 <TxnDet.ReturnIn- TransactionDetails>ReturnInformation>Reason>Code O

foReasonCode>
2.306 <TxnDet.ReturnIn- TransactionDetails>ReturnInformation>Reason>Proprietary Y O

foReasonProprietary>
Add Info
2.313 TxnDet.AddTxnInfo TransactionDetails>Additional Info Y O
Reference Documents
XML message for Bank to Customer Statement (camt053) Implementation Guidelines for Netherlands.

Glossary of Terms
SWIFT SWIFT is the abbreviation of Society for Worldwide Interbank Financial Tele-
communication and is a communications network used by most of the banks in the
world for sending each other payment instructions and messages.
SEPA The Single Euro Payments Area (SEPA) is an initiative of the European banking
industry to make electronic payments across the euro area – e.g. by credit card, debit
card, bank transfer or direct debit – as easy as domestic payments within one coun-
try. One of the first steps taken by the European Commission was in 2001 when
they introduced the EC 2560/2001 regulation on cross-border payments (This reg-
ulation was later replaced by regulation EC 924/2009). Since then, banks have been
able to make the first SEPA products available since 1 January 2008 and the aim is
to make SEPA available to everyone by the end of 2010.
INDEX Number that refers to the corresponding description in the UNIFI (ISO 20022) Mes-
sage Definition Report for Bank-to-Customer Cash Management
XML Tag XML: Extensible Mark-up Language .Short name that identifies an element within an
XML message, that is put between brackets, e.g. <Amount >
UNIFI Stands for “Universal financial industry”
The camt message is defined by ISO 20022 Universal financial industry message
scheme (UNIFI). Messages are based on XML (Extensible Mark-up Language
ISO 20022 ISO 20022 was developed and is maintained by ISO/TC 68, the ISO technical com-
mittee responsible for standardization in the field of banking, securities and other fin-
ancial services. Its current portfolio consists of 49 standards or related documents
and its membership comprises the NSBs of 28 countries, plus the following stake-
holder organizations: CEFACT, ECB, MasterCard, SWIFT, TWIST,UNECE, VISA.
NVB Stands for NederlandseVerniging van Banken, which means the Dutch Banking Asso-
ciation

AC.STMT.PARAMETER - Defaults for Account Statements
This is a high level parameter table, which is used by the system when creating the default ACCOUNT.STATEMENT records, when new
accounts are opened in the system. Various flags can be set within this record, which will then be used to determine whether the default
ACCOUNT.STATEMENT record is set to do the following:
l Produce statements when there has been no movement

l Produce descriptive statements
l Produce interest and charges statements and advices
l Produce tax advices
l Calculate the minimum number of months for a statement to be produced if at all.
l Provision to call a local API to populate extra handoff details (mainly to populate sub items in Tag 61 and Tag 86).
If no record exists, the default will be 'NO' and the minimum frequency will be six months. These settings can of course be overridden on the
ACCOUNT.STATEMENT record itself.
The field FWD.MVMT.REQD is used in a value dated account system only. If this field is no or null then real forward entries with a value date
equal or less than the next statement date, booked during the statement period alone will be reported in the statements. If it is desired that all
the real forward entries irrespective of value date booked during the statement period, are to be printed in the next statement then this field has
to be made YES.
For example
l Last statement date is 15/03/2008

l Next statement date is 31/03/2008
l Booking date is 15/03/2008 – Value date is 28/03/2008
l Booking date is 31/03/2008 – Value date is 05/04/2008
If this field is no/null, then only the entry with a value date 28/03/2008 will be reported in the next statement due on the 31/03/2008.
However, if this field is set to 'Yes', both the entries will be reported in the next statement due on 31/03/2008.
It is possible to suppress interest and charges statements so that they will not be produced, using AC.STMT.PARAMETER field
INT.STMT.AND.ADV. The options are Yes, No or None.

l YES statements will be produced regardless of what is input in the ACCOUNT.STATEMENT.
l No and NONE statements will not be produced in the normal fashion.

ACCOUNT.STATEMENT - Statement Details for an Indi-
vidual Account
A record will be created automatically by the system for each new account that is opened. This record controls the date and frequency for print-
ing statements, whether statements are to be printed if there have been no movements and various other statement production options for
each account. 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. The key to the table is an ACCOUNT number.
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:
l MT940 – Customer Statement

l MT941 – Balance Report
l MT942 – Ad-hoc statement
l MT950 – Statement

Statements can be produced every working day, for 1-9 weeks, twice a month (on the 15 th and the last day of the month) or for 1-12 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:
l Separate: Statements for each cycle show details of all entries since the last statement in the same cycle, regardless of the other cycle.
l Combined: Statements are produced on the dates specified by both cycles, but only contain details of entries since the last statement
from either cycle.
If there have been no entries since the last statement, the statement may be suppressed unless six months have elapsed.
Special interim statements, showing details of all entries since the last regular cycle 1 statement, maybe 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 is made
immediately, together with the production of a debit advice, detailing the charge made when the duplicate statement is produced.

Non Printing of Internal Account Statements
The PRINT.STMT field in ACCOUNT.STATEMENT is an optional input, and can only be made for Internal Accounts. The value of this field
can be Null, Yes or No. The following are examples for an Internal account and for a customer account.
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).

STMT.GEN.CONDITION
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. STMT.GEN.CONDITION and
will currently accept records for the following frequencies:
l DAILY (every working day)

l WEEKLY
l WEEK2, (Will accept 2 till 9)
l MONTHLY
l TWMTH
l QUARTERLY
l SIX.MONTHLY
l YEARLY
The following screen shot shows the STMT.GEN.CONDITION record for SIX.MONTHLY
The table STMT.GEN.CONDITION allows users to define the criteria for which, the PRINT.STMT is defaulted as ‘NO’ in
ACCOUNT.STATEMENT. Also, the criteria is defined in the STMT.GEN.CONDITION and is based on the conditions set in
CONDITION.PRIOITY. Further, any frequency changes can be done in the table ACCOUNT.STATEMENT by setting the field YES in
PRINT.STMT

Swift MT942
The ACCOUNT.STATEMENT application also allows for the production of SWIFT MT942 messages. Five fields on the
ACCOUNT.STATEMENT record control MT942s:
l MESSAGE.TIME - A multi valued field containing all the times during the day that the Message is to be produced.
l DR.FLOOR.LIMIT - The minimum value of a transaction that is to appear on the statement. Any transactions below this amount,is
not included on the statement
l CR.FLOOR.LIMIT - The minimum value of a transaction that is to appear on the statement. Any transactions below this amount, is
not included on the statement
l MESSAGE.TYPE - As shown here, the 942 message type has to be entered-
l SEND.MSG.MT942 - Must be ‘Y’ or ‘N’
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 pro-
duce Interim Transaction Reports (SWIFT MT942) online on an ad- hoc basis. Requests are entered through the application
DE.MT942.REQUEST where T24 produces an Interim Transaction Report on the account specified. Note the 'V' function is required to
invoke the message creation.

IX Module Related Changes

Overview
Banks that participate in SEPA payments, both credit transfer or direct debit, acting for the ordering party or the beneficiary are required to be
able to generate the Camt053/052/054 messages, which are standard account reports based on movements across the account over a specified
period of time.
These are part of the family of cash management messages (Camt) format of the ISO20022 (also known as UNIFI) standard using an XML
based schema.
The format should include full details of the SEPA payment in the statement detail, as well as details of other non-SEPA financial transactions.
This capability became mandatory in many European countries since February 1st 2014.
The Camt053 (Bank To Customer Statement) message is a statement of account(s) sent by the bank to the account holding customer (or nom-
inated representative) on a periodic basis. .
The Camt052 (Bank to Customer Account report) is used for intra-day account reporting upon request by the account owner.
The Camt052 message is an intra-day version of the Camt.053, showing movements generated since the last Camt052 or Camt053 was gen-
erated.
The Camt054 message (Bank to Customer Debit Credit Notification) is a report of selected transactions processed across the account during
the requested period and does not include account balances.
The CAMT messages are the ISO20022 equivalent of the MT9nn series:
l Camt053 is the ISO20022 equivalent of MT940, which is an account statement sent by the Bank to the Account holder on a periodic
basis
l Camt052 is the IS020022 equivalent of MT942/MT941, which is an intra-day version of the Camt053 reporting intra-day trans-
actions and balances
l Camt054 is the IS020022 equivalent of MT900/MT910, which is a notification of selected transactions but no balance data

Structure of a Camt Statement
A Camt message has a nested structure with the building blocks as shown in the following diagram. The T24 Camt Module is responsible to
assemble the data necessary to produce a Camt message for each statement triggered.
Camt052, Camt053 and Camt054 messages have the same structure, except for the header name that is different and Camt054 does not have
balance details.
The Camt053 message has the following structure:
Bank to Customer Statement
l Group Header
l Statement
l Entry
l Transaction details
Camt052 has the following structure:
Bank to Customer Account Report
l Group Header
l Report
l Entry
Camt054 has the following structure:
Bank to Customer Debit /Credit Notification
l Group Header
l Notification
l Entry
Structure of a camt053 message
GroupHeader – (Statement Level Information)

The “GroupHeader” block of the Camt message provides information related to the statement and is specified once for the Camt message. This
section of the message is mandatory.
It will contain information such as the Message Identification, Pagination, message recipients and so on.
Note: (1..1) denotes that this section is for mandatory and will occur only once in the Camt message.
Statement or Report – (Account Level Information)
The “Statement” section of the Camt message provides the details of the account (s) for which the statement(s) is being produced.
The Camt message may contain information related to more than one account statement, however, T24 is producing one Camt message for a
single account statement.
Details required at this level are built from the T24 account and related statement production details. This will include details of the statement
period, account identification, opening, closing and other account balances.
Note: (1..n) denotes that this section is mandatory and may occur multiple times in the Camt message.
Entry Level Information
One account statement can contain multiple account movements (a statement may have zero entries during the period). Information at this
level is derived from the individual account movement from the T24 statement entry table.
Note: (0..n) denotes that this section is optional and may occur multiple times in the Camt message.
Transaction Level Information
This section provides additional information for each entry displayed in the “Entry Level” section.
The additional information may include:
l Additional details for an individual entry

l Additional details for SEPA related transactions
l The underlying entries for an individual entry, which is a net movement representing multiple debits and credits or a batch entry. (This
will be supported at a later stage).
Note: (0..n) denotes that this section is optional and may occur multiple times in the Camt message.
The following diagram shows the xml view of the Camt053 message: ***

Accounts Turnover Reversal
When transactions are reversed, T24 can be configured to stop reversals from affecting the turnover figures in ACCT.ACTIVITY (the
TURNOVER.CREDIT and TURNOVER.DEBIT fields). The field REVERSE.TURNOVER in the ACCOUNT.PARAMETER record should be set
to Yes. Once set to Yes, this can not be changed. The TURNOVER.CREDIT and TURNOVER.DEBIT fields are updated with credits and deb-
its respectively. When there is a reversal movement, and the field REVERSE.TURNOVER is set to Y, reversed debits will update
TURNOVER.DEBIT and reversed credits will update TURNOVER.CREDIT.
For example
The field REVERSE.TURNOVER is set to Yes in the ACCOUNT.PARAMETER record.
An FT has been passed to credit ac 10561. In the screen shot shown below, the TURNOVER.CREDIT field of the ACCT.ACTIVITY for AC
10561 has a value of 1000. If the FT is reversed, the ACCT.ACTIVITY record will be updated as follows. Note that he value of
TURNOVER.CREDIT is now zero, as shown in the following screen shots (before and after scenarios).

Using the same scenario above, if the field REVERSE.TURNOVER in the ACCOUNT.PARAMETER record is set to either No or Null, the
reversal entry would update the ACCT.ACTIVITY record as follows, thus leaving a turnover in the ACCT.ACTIVITY record for the account.
Notice the reversal has updated the TURNOVER.DEBIT field.

When the REVERSE.TURNOVER is set to Yes and Data Capture is used to reverse entries, in the enquiry ACCOUNT.STATEMENT, the
reversal of a credit will show the debit amount displayed under the credits column and reversal of a debit will show the credit amount under
the debit column.

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 con-
cerned. 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 = Yes).
This file is updated daily during the End-of-Day processing and online or manually if a transaction needs to be added or a status changed. Trans-
actions 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.
This screen shot shows an example account, which has broken the rules set in the ACCT.GROUP.CONDITION. Two debit entries have broken
the conditions:
l - 8000.00
l -4,000.00

The AC.VIOLATION record for account 25577 contains the details of the STMT.ENTRY records that violated the conditions.
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.

Limits
The LIMITREF 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 products, 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.

Accounts with Notice Periods
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 should be given, which satisfies the notice conditions set up on the ACCT.GROUP.CONDITION application.
The application NOTICE.WITHDRAWAL records the withdrawal notice given by the holder of the savings account. It stores the amount that
can be withdrawn and the date when the funds will be available.

ACCT.GROUP.EVENT
The table ACCT.GROUP.EVENT holds the list of valid events that are allowed for an account group. The fields EVENT.TYPE and EVENT
establish the link to eligible event types defined in EB.EVENT.TYPE and TEC.ITEMS applications to the account group. The ID of this table
should be a valid record in ACCT.GEN.CONDITION.

Additional Rules for Groups of Accounts -
ACCT.GROUP.CONDITION
The record ID for the parameter file ACCT.GROUP.CONDITION is the condition group and the currency of the account(s) i.e. 1USD.
Rules on deposits, withdrawals and premium interest applying to accounts belonging to a condition group and defined for a 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.
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 fol-
lowing example demonstrates how this may be achieved.
In the example, 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, five transactions. If this threshold (TXN.THRESHOLD) is exceeded, the account is in viol-
ation and this will be recorded on the account violations file (AC.VIOLATION). The above example is set up to record violations if more than
five cash withdrawals or more than three 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 is then transferred to the AC.VIOLATION.HIST file. The record will 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 accounts opened, under the group, the single limit field
in account is defaulted with 'Y'.

Alternative Account Numbers
In practise where T24 has replaced an existing system it could 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 is set-up. This tells T24 how the other system
account number structure was defined.
After 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 con-
tains the T24 equivalent.
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. The workflow to extend capacity of the
ACCOUNT field is as follows:

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 the 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.
In the field 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.

Change of Main Customer
There can be a requirement for the customer in an account record to be modified with that of another customer, in cases like death of the
primary 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, but 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 screen shot shows the example set-up of CATEGORY range in 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.

High Volume Processing
Introduction to High Volume Account Performance

l High volume account processing
l The ability to create net statement and category entries automatically and so reduce high volumes of entries
l The ability to keep the detail behind net entries for detailed investigation
l Detailed entries can be archived frequently to reduce the size of the database
Accounts with High Volumes

The accounts that can use the high volume processing are:
l Nostro Accounts
l Clearing Accounts
l Customer accounts - There is a restriction on customer accounts created through AA; these are currently not able to use this func-
tionality.
l Internal accounts used for purposes such as inter-company accounting, reserve accrual, off balance revaluation, suspense processing
and general ‘wash’ accounts
There is no limit checking on high volume accounts.

High Volume Accounts
Overview
Certain types of financial transaction can require account postings to be made to the same account; where the volume of these transactions are
high, the result is a high number of postings across the account. Typically this scenario can occur when one side of the transaction is the bank
itself so an internal account (or nostro account) is updated as the ‘other side’ of a customer transaction. This can also happen when a bank has
corporate or retail accounts that attract high volumes of transactions.
When an account posting takes place a number of tables related to the account are updated with details of the posting and the updated account
balances.
The high-volume account solution provides standard account functionality in a seamless manner to the end user, avoiding any concurrency
issues and allows the system to be scalable.
When to Use High Volume Accounts?

High volume accounts should be used where there are likely to be significant volumes of movements generated across the account that need to
be completed in as short a time frame as possible. Possible candidates are:
l Internal accounts used for collection of TAX and Charges, these are frequently high volume operations both online and as part of
the COB
l Internal suspense accounts – bulk payments are frequently processed through individual suspense accounts. For example, a com-
pany salary payment batch will typically result in a debit to the corporate account initially and a credit to a suspense account. Each
‘child’ payment is then made to the individual staff member by debiting the suspense account.
l Nostro accounts – where the bank needs to make a payment externally, a Nostro account is usually credited by the transaction issu-
ing the payment. High volumes of transactions can be processed both online and offline.
l High volume customer accounts – certain accounts owned by customers may also process high volumes of transactions, both
online and offline
There is a mechanism in T24 to enable high volume processing for accounts. The field HVT.FLAG in the account record controls whether an
account is high volume or not. A value of No or Null indicates that it is not a high volume account. If this field is set to Yes it indicates that
this is an account, which has a high volume of transactions every day. High volume account processing is currently not enabled for AA
accounts.
For high volume accounts there is no limit checking.
Once an account has been flagged as a High volume account when transactions are processed the details of the transactions are written to the
file AC.HVT.TRIGGER. The ID to this file is ACCOUNT.ID!SESSION.NO!DAY!TIME

This record also contains the IDs to the files that have been updated by the transaction. For example:
l STMT.VAL.ID
l ENT.FWD.ID
l AC.VIOLATION
l FWD.STMT1.ID
Once a merge has been triggered, the information from the AC.HVT.TRIGGER records will be merged and the EB.CONTRACT.BALANCES
record will be updated. The other accounting files where multiple entries have been created with suffixes for the high volume processing, such
as STMT.PRINTED will also be merged at this time, creating one record for the account.
The merging service will run automatically at defined intervals during the online phase and will be forced to run at critical points during close of
business to ensure that all relevant data for a high volume account is merged. During close of business data from non stop transactions with a
booking date of next working day will not be merged until the start of day processing begins.
The defined interval is set through HVT.MERGE.INTERVAL on ACCOUNT.PARAMETER, which can be from 1 to 99 minutes. The default
interval for online merging is 15 minutes.
There are 3 types of merging:
l Notional Merge – where the balances are merged online for enquiry purposes
l Online Merge – The service can be run online. This merge will not include entries in the current defined period.
l Real Merge – This is processed during the COB and the system will process all the records.
The following diagram explains the flow for high volume accounts

Refer to the High volume account section in deal processing for an example.

Inactive Accounts
The field INACTIVITY.MONTHS in the COMPANY record indicates the number of months without customer activity before an account is
declared inactive. An account is marked to inactive during the close of business.
Declaring an account as inactive after a specific period can also be set at group level through the field INACTIVE.MONTHS in
ACCT.GROUP.CONDITION.
When inactivity period is defined both at the company level and at group level, what is set at ACCT.GROUP.CONDITION takes precedence
over what is set in COMPANY. If not specified at group level, the inactivity period defined in COMPANY will be considered in marking the
account as inactive.
This account record has the field INACTIV.MARKER set to Y.

The application ACCT.INACTIVE.RESET is used to remove the inactive setting in the account. The value of the RESET.DATE must be today.
During the Close of Business, the INACTIV.MARKER field in the account record will be cleared.

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 the currencies that 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 auto-
matically 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 generates the single netted payment.
During the review of the NETTING record, individual payments can 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 applic-
ation) for spot deals.
The accounting entries for payments that are to be passed across a suspense account, should have a zero balance once all net payments have
been sent.
Individual payments that are to be netted 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.
l Accounting for net payments

Accounting for Net Payments
Payments that are netted pass across a suspense account. For example, if we are paying US dollars to a counter party 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:
Standard Accounting Entries
DR/CR Account Amount CCY Value Generated by
Credit Nostro 15M USD Spot Contract
Debit Nostro 12M USD Spot Contract
If the payments were netted, then T24 would generate the following:
Accounting Entries with Payment Netting
DR/CR Account Amount CCY Value Generated by
Credit Netting Suspense 15M USD Spot Contract
Debit Netting Suspense 12M USD Spot Contract
Debit Netting Suspense 3M USD Spot Netting
Credit Nostro 3M USD Spot Netting
All entries in the above examples are STMT.ENTRY records.

Payment Netting Setup
The following steps are to be followed:
1. Setting up the payment netting suspense accounts

2. NETTING.PARAMETERS
3. NETTING.AGREEMENT
4. CREATE.NETTING
5. NETTING.ENTRY
6. NETTING application

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 cre-
ated 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 sus-
pense 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.
After 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. E.G USD149550001.

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

NETTING.PARAMETERS
The NETTING.PARAMETERS application controls the payment netting facility. Only one record may exist (with the ID of the system). It spe-
cifies 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. 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.

CREATE.NETTING
This application is used to create netted payments on-line. Verification of a CREATE.NETTING record will activate the payment netting pro-
cess. 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 and so on. The specification of counter party is mandatory.

NETTING.ENTRY
The NETTING.ENTRY application contains details of all entries being netted. Records are created here upon authorisation of the original con-
tract. When an individual payment is 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.
The NETTING.ENTRY record also holds details of the status of each individual payment. Each individual payment can have one of two
statuses:
l waiting to be included in a net payment

l 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 is updated with the reference of the NETTING record.

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 remain in suspense until captured in another net pay-
ment. 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 con-
firmation with the counterparty), it should be authorised. T24 then generates the single net payment.
The NETTING record in this example has used the example from the NETTING.ENTRIES page.

This screen shot shows the authorised NETTING record.
Settlement details, such as bank to bank-to-bank information, may be added to the NETTING record and is 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 remain in suspense until another netting record is generated (either in the T24 batch or by the CREATE.NETTING application).

The file POSTING.RESTRICT contains various types of restrictions that may be defined, such as:
l ‘Post No Debits’
l 'Whereabouts Unknown’
The system will automatically close any ACCOUNT that has a posting restriction in the 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.
Posting Restrictions can be imposed on selective transactions by setting values in the fields ALLOW.TXN and TXN.CODE in the
POSTING.RESTRICT application. The following possible values can be input:
l If ALLOW.TXN is set to "N", posting restrictions will be applied only on the transaction codes listed in TXN.CODE.
l If ALLOW.TXN is set to "Y”, posting restriction functionality will be applied on any transaction code except those listed in
TXN.CODE
l If ALLOW.TXN field is Null, posting restrictions will be applied on transactions based on RESTRICTION.TYPE
l If ALLOW.TXN and TXN.CODE are set, RESTRICTION.TYPE need not be input. However, when both RESTRICTION.TYPE and
TXN.CODE fields have values input, TXN.CODE will take precedence and posting restriction will be applied only based on

ALLOW.TXN and TXN.CODE set up.
For an example set up on a customer account, refer to Client Account section of the user guide.

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 and so on.
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.

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 and so on are defaulted in Applications such as LD and MM. 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.
Example: LD-INT, which refers to the interest liquidation account in the LD application, can have a record in AC.SYS.CODES as follows:
CUSTOMER.SSI is an application that is used to define the Standard settlement instruction (SSI) for a particular custome,r which is then used
to default settlement account fields such as DRAWDOWN account, PRINCIPAL, LIQUIDATION ACCOUNT and Interest Liquidation Account,
in applications such as LD, MM, FX, MG, NETTING, BL.BILL, PD.CAPTURE and PRE.SYNDICATION.FILE. The field CUSTOMER.SSI in
the ACCOUNT.PARAMETER is used to control the above feature.
If this field is set to “YES” (along with the DEFAULT.ORDER field of the required sys-code field set 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 the case where 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 the case where the CUSTOMER.SSI field in ACCOUNT.PARAMETER is set as ‘blank’, 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. 1025 (Richard Branson):

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

Statement Print Mask
It is possible to mask accounting entries, where entries have been posted incorrectly and had to be reversed out, or for 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 reconciliations. 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. The entry will not be removed from the account and the transaction will not be deleted, but it 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 selec-
ted 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.
l AC.PRINT.MASK

AC.PRINT.MASK
As mentioned before, the AC.PRINT.MASK application is produced to allow users to 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 val-
idations of the application.
First of all, run the application AC.PRINT.MASK and capture an 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 PGM.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” for this mandatory
field.
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 given below
that explains how to run the enquiries and to copy and paste the relevant entries into the MATCHED.TO and MATCHED.FROM fields.

This is an example of all the statement entries that are associated with account number 1189. To bring up this list, you have to run an enquiry
on the STMT.ENTRY application of all entries that belong to the particular account that you want to mask.
After you find the statement entry that you wish to mask or unmask for printing on the enquiry list, you can double-click on the statement
entry and the full record for the statement entry will then be displayed as shown. You then highlight the statement entry ID at the top of the
record and right-click on the mouse and copy the ID.
After you copy the statement entry ID, you can go back to running the 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 enter. Once you enter, the fields
TO.TOTAL and FROM.TOTAL as well as the NET.TOTAL field will be updated with totals from 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 are either masked or unmasked for printing at a later stage.

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.
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.

Unauthorised Entries for Accounts
Updates for Unauthorised entries from transactions are stored at Account level. These updates give the following benefits:
l To help in Account closure validation when closing an Account that has unauthorised transactions.
l To properly rebuild an Available funds ladder if unauthorised transactions exist for an Account.
l The ability to produce a report and enquiry to show the list of unauthorised entries for an Account.
Holding Unauthorised Balances
l The EB.CONTRACT.BALANCES file holds unauthorised Credit and Debit balances in separate fields.
l There are also separate sets of fields to hold Forward and real unauthorised balances.
l Updates are performed through the existing Accounting Framework.
The ACCOUNT.PARAMETER application contains a NO.UNAU.KEYS field that holds the limit threshold for the number of unauthorised keys
to be held in the EB.CONTRACT.BALANCES file.
In this example, the maximum threshold limit for storing unauthorised keys in EB.CONTRACT.BALANCES is set to three.
When the threshold limit is exceeded the updates are moved to the AC.UNAUTH.ENTRY application, or AC.FWD.UNAU.ENTRY, through a
Service. Both applications are keyed by Account number with each record containing the Transaction IDs.
The Service operates from the files AC.UNAUTH.TRANSACTION and AC.FWD.UNAU.TRANSACTION keyed by the Transaction Id and con-
taining the Account IDs, and the operation such as Input and Delete.
The EB.CONTRACT.BALANCES file is used to store the unauthorised transactions for an account. The following fields are updated with the
unauthorised transaction data.
l TOT.UNAUTH.CR – Holds the total unauthorised credit balance

l TOT.UNAUTH.DB – Holds the total unauthorised debit balance
l TOT.FWD.UNAU.CR – Holds the total unauthorised forward credit balance
l TOT.FWD.UNAU.DB – Holds the total unauthorised forward debit balance
l UNAUTH.KEY – Multi valued set of transaction IDs that make up the unauthorised balances, which link to the internal
ENTRY.HOLD file
l FWD.UNAUTH.KEY – Multi valued set of forward transaction IDs that make up the unauthorised balances, which link to the
FWD.ENTRY.HOLD file.

US Regulation D Compliance
In order to allow the recording of any Regulation D violation on-line, the Core Accounting module facilitates this regional requirement, by allow-
ing 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 can 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 as an ‘S’ type in PGM.FILE.
ACCOUNT.PARAMETER
The Core Accounting routine will fetch the local routine if it is defined in ACCOUNT.PARAMETER under ACCT.NAU.SUBRTN.
Override Messages
When a transaction is being processed, the Core Accounting routine will process all the system overrides and will then 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 shows a Funds Transfer input and the flow of the override messages. Once the system overrides have been raised, then the local
ones will be raised.

Accounts Deal Processing Overview
The accounts deal processing section covers the following areas:
l Internal files
l High Volume Accounts
l HVT Parameterization

Internal Files
The following internal files are explained:
l ACCT.ACTIVITY - History of account activity

l ACCT.AVAILABILITY - History of availability of funds on Accounts

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 cal-
culation 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.

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.

The new account 66093891 has been set as a high volume account.
The following EB.CONTRACT.BALANCES record for the account before any transactions over the account, is shown in the following screen-
shot:
When a new account is opened and set to High Volume, the EB.CONTRACT.BALANCES record is created with an OPEN.ASSET.TYPE as
NILOPEN.
Two funds transfers are entered crediting the account 66093891.

Once these transactions are entered, the AC.HVT.TRIGGER is updated with the transaction details. The following screen shot shows that two
records have now been written into the file for the account 66093891

The EB.CONTRACT.BALANCES record for the account after the FT records have been authorised is shown in the following screenshot. This
has not been updated as the AC.HVT.TRIGGER records have not been merged.
In addition to the AC.HVT.TRIGGER, other accounting files are also updated for High volume accounts, which will be merged. The
STMT.PRINTED file for High volume accounts is updated by: ACCOUNT.NO!SESSION.ID!DATE!TIME. The following is the
STMT.PRINTED for our account used in the example above.

The ACCT.STMT.PRINT and STMT.VAL.ENTRY files are updated in a similar way and shown in the following example.
After the merge is run either during the Close of Business or manually online, the AC.HVT.TRIGGER records will be merged and the
EB.CONTRACT.BALANCES record updated is shown below:

As have the other entries on the other accounting files. The entries on the STMT.PRINTED file have been merged into the record 66093891-
20010210

The following is the actual STMT.PRINTED record that shows both STMT.ENTRY numbers.
The records in ACCT.STMT.PRINT have been merged into one entry for the account 66093891.
The entries in the STMT.VAL.ENTRY have been merged into the one record as shown below.

HVT Parameterization
A C .H VT.PA R A METER
The application AC.HVT.PARAMETER is designed to overcome the restrictions in the current design.
1. HVT parameterization is set at company level or system level or both a company level and system level. For each lead company a dif-
ferent parameter table is defined.
a. At Company Level , the set up has the following restrictions:
i. HVT Category setup is same as System level setup and changes are blocked.
ii. Time Interval and Non HVT Job setup can be changed.
2. Accounts with multiple categories can be defined for HVT processing at company level. Option is provided to either exclude or include
a defined range of category of accounts for HVT default processing.
Example:
In the above example, default HVT is set as YES and the Category range is defined from 1002 to 5999.
It means that all the accounts except category 1002 to 5999 are defaulted as HVT. In other words, HVT on fly process is applicable to all
accounts except the accounts that belong to the category range 1002 to 5999.
However, the exception to default logic is applicable.
3. Default logic: Once the parameter is defined, the system does not default HVT.FLAG in the account. Instead HVT processing will be
decided on the fly based on the setup in the parameter.
4. NON.HVT.JOB: If system is running under a job, which is given in the AC.HVT.PARAMETER- NON.HVT.JOB field, then HVT pro-
cessing will not be applied for customer accounts (Except Nostro Accounts). When these jobs run, they will override any HVT default
or individual account settings and will read and update the account related tables directly. All these jobs should be written in such a
way so as to eliminate or minimise any locking contention on customer accounts.
Exceptions to Default Logic:
1. The default HVT can be overwritten manually at individual account level.

2. During upgrade, all the master accounts will be converted as HVT by default, and the rest of the accounts that are not converted dur-
ing the upgrade process will follow the rules set in the new parameter design. If the account does not have any value in the HVT.FLAG
field, then during transaction, the system decides whether HVT processing is applicable for this account based on the new parameter
setup.
3. If the parameter is not setup, the existing design will continue to decide the default HVT flag. i.e. the following accounts only will be
set as HVT by default and the other accounts need to be set manually.
a. Local currency internal accounts
b. Position accounts

c. Nostro accounts
4. Exceptions to the parameter setup are:
a. AZ – ALL IN ONE accounts cannot be set as HVT even if the default value in the parameter is YES, because AZ needs sub
accounting process
b. AA - Arrangements account cannot be set as HVT, because AA needs sub accounting process for suspense account processing
c. When account is set to have passbook i.e. SAVING BOOK ACCOUNTS cannot be set as HVT accounts.
d. Teller cash accounts (defined in TELLER.PARAMETER) cannot be set to HVT accounts. This is because there will be only
one Internal Till Account per Cashier.
The following charts can be referred to:
Chart 1: For Upgrading from R09 to R13
Chart: 2: In R13
Note:

1. HVT Flag Update :
a. NO: Means HVT field in account record marked as “NO”

b. YES: Means HVT field in account record marked as “Yes”
c. NULL: Means HVT field in account record will be blank.
2. HVT A/c:
a. YES : Means HVT processing will be applicable.

b. NO : Means HVT processing will not be applicable.
3. Enrichment speciality of populating HVT as “YES” or “NO” with comment “Defaulted by System” is provided even though HVT flag will
be NULL in the account record.
Example:
The following two records are created in AC.HVT.PARAMETER table.
Note:
1. As a separate record has not been created for EU0010001, the company follows SYSTEM record.
2. The company US0010001 supersedes the SYSTEM record.
3. For Teller Cash Account and AC5 account with passbook facility, the HVT flag is not updated even though it is not included in the cat-
egory range for HVT processing in US0010001 record.
4. If the SYSTEM record is created first, and then the COMPANY record, the only input possible in the COMPANY record is the Active
time. The category ranges defined in the SYSTEM gets defaulted in the Company.
H VT.A C TIVE.TIME
The interval time can be defined at ACCOUNT.PARAMETER level, System- AC.HVT.PARMETER level or/and Company-
AC.HVT.PARAMETER level. If defined in all, then the following logic applies:

l System-AC.HVT.PARMETER will override ACCOUNT.PARAMETER
l Company-AC.HVT.PARMETER will override System-AC.HVT.PARMETER
If not defined anywhere, then the default time is 15 minutes.
It is important to note that a new AC.HVT.TRIGGER record is updated only if any transaction hits the underlying account. For example, with
the default merge interval of 15 minutes, if the account hits with one transaction in an hour, then only one trigger record will be created, and
not four with each 15 minutes.
Transaction updating and merging process for HVT accounts:
To avoid locking contention, transactions for the HVT accounts do not update the account balances and its related tables directly. It will be
recorded in AC.HVT.TRIGGER (live file that holds the transaction details of the HVT accounts before merging) and later merged with the cor-
responding account’s main record by the running the service behind within the defined HVT.MERGE.INTERVAL time.
EB .C ON TR A C T.B A LA N C ES
The field LAST.MERGED.TIME in EB.CONTRACT.BALANCES application holds the time when the balances for the HVT account is merged
and updated.
(c) Temenos Systems 2015

Unauthorised Entries for Accounts Example
The following EB.CONTRACT.BALANCES record has been updated with the keys to three unauthorised funds transfer transactions with a pro-
cessing date of today and forward date funds transfer.
The threshold on the account parameter has been set to three. The next unauthorised transaction with a processing date of today will exceed
this and the file AC.UNAUTH.TRANSACTION will be updated with the last transaction ID.
The following is the updated AC.UNAUTH.TRANSACTION record for FTFT1010D11F3SFFS. It updated with the account numbers involved in
the transaction.
The following EB.CONTRACT.BALANCES record for the account 66093913 shows there are now four forward dated funds transfers over the
account. As the forward transaction also exceeds the threshold set on the account parameter, the AC.FWD.UNAU.TRANSACTION file will be
updated with the details of the fourth transaction.

The AC.FWD.UNAU.TRANSACTION record is updated with the accounts involved in the transaction.
Once the service AC.ACCOUNTING.SERVICE is run, the information in the fields UNAUTH.KEY and any transaction written to the file
AC.UNAUTH.TRANASCTION are merged and written to the file AC.UNAUTH.ENTRY. The information in the fields FWD.UNAUTH.KEY and
any transaction written to the file AC.FWD.UNAU.TRANSACTION are merged and written to the file AC.FWD.UNAU.ENTRY. The fields
UNAUTH.KEY and FWD.UNAUTH.KEY in the EB.CONTRACT.BALANCES and the files AC.FWD.UNAU.TRANSACTION and
AC.UNAUTH.TRANSACTION are cleared.
The following are the EB.CONTRACT.BALANCES record, AC.UNAUTH.ENTRY and AC.FWD.UNAU.ENTRY records for the account
66093913 after the merge has been run.
The fields UNAUTH.KEY and FWD.UNAUTH.KEY have been cleared, but the total fields are still updated with the total unauthorised move-
ments.

If the service is running in the background then the EB.CONTRACT.BALANCE fields will be merged and cleared as soon as the threshold is
exceeded.
In the following example, a Forex transaction is being reversed, the reverse is unauthorised.
As this is a reversal of a credit entry, the field TOT.UNAUTH.DR is updated with a negative figure as in the field AV.NAU.CR.MVMT.

Trade Dated GL Balances
For future dated movements under the “TDGL” accounting treatment, the customer's balances are updated on the value date. However, the Bal-
ance sheet and General Ledger is updated on the trade date but under Payable/Receivable.
These movements are recorded and a Trade dated GL balance is also maintained in the EB.CONTRACT.BALANCES table to show effect of
these movements:
l AUTH.PAY.MVMT: holds the authorised future dated movements under “PAY”

l AUTH.RECEIVE.MVMT: holds the authorised future dated movements under “RECEIVE”
l TRADE.DATED.GL.BAL = (ONLINE.ACTUAL.BAL + AUTH.PAY.MVMT + AUTH.RECEIVE.MVMT)
The following screenshot shows an example of the future dated movements under “PAY”.

Trade Dated GL Balance for Credit Checking
As under the TDGL Account, the account balances are not updated with the future dated movements, until the value date, it is still possible to
include these movements in the balance used for Credit Checking.
The flag must be set in ACCOUNT.PARAMETER to include these balances as shown below:
With this set-up, the balance used for Credit Checking on the Current balance (not on the future cash flows) will include the Auth.Pay.Mvmt
and Auth.Receive.Mvmt.
Note: The LIAB enquiry shows the Account balance including the Auth.Pay.Mvmt and Auth.Receive.Mvmt
How to - Trade Dated Accounting Systems

Statement Processing
The ACCOUNT.STATEMENT record defines the frequency of statement production, for a high volume account that is using SWIFT. This
would typically be generated on every business day.
T24 supports the 950 and 940 statement message types, also specified in ACCOUNT.STATEMENT. The default statement type is 950.
Although a SWIFT message type is used to identify the type of statement required, the system does not necessarily generate it in SWIFT
format.
Through T24 delivery, the DE.PRODUCT definition specifies the carrier that the statements should be produced through SWIFT or PRINT.
For PRINT statements, an additional setting in DE.PARM (BYPASS.PRINT.STATEMENTS) identifies that the printed statement is formatted
outside of delivery.
STATEMENT.CONTROL
A new field MAPPING.ROUTINE is introduced in the application STATEMENT.CONTROL and this field is used to attach a routine, which
will be called while preparing an account statement. This can only be used for statements sent through SWIFT format.
Producing Account Statement using Segmentation Process.
A new service (AC.STATEMENT.SERVICE) is introduced and this service will pick up all the accounts from the detail record and use ‘Segment’
technique available in job list preparation to distribute and process a pre-determined set of entries per account, across multiple agents. Each
agent follows the generic statement process and updates the delivery files (DE.O.HANDOFF, DE.O.HEADER and so on) for the entries pro-
cessed in that session. The activation file for the formatting service is not updated so that they are not picked up by delivery SWIFT formatting
service for processing as the final statement is not completed.

Another new job AC.MEGE.SEGMENT.HANDOFF takes all the segmented delivery records per account number (Delivery references generated
by previous job) and sorts in order by segment number and merges them into a single handoff record.
The final delivery reference will be updated in the ACCOUNT.STATEMENT, which would refer to the single DE.O.HEADER record that also
has frames after going through SWIFT formatting service. This single merged delivery will be the handoff record that is picked up and formatted
by SWIFT service.

Services Overview

The service AC.HVT.MERGE.SERVICE is used to merge the AC.HVT.TRIGGER records that are created by entries to high volume accounts.
The service will take the information in the AC.HVT.TRIGGER and update all the relevant accounting files. For example:
l EB.CONTRACT.BALANCES
l STMT.ENTRY
l STMT.PRINTED

Enquiries and Reports Overview

Account Overdrawn
This internal file is used to record overdraft details for:
l An account with no limit that goes into overdraft

l An account with a limit where the limit goes into excess
It records information about the overdraft details for the account or the limit, which include:
l Account officer
l Customer
l Currency
l Cleared Balance Limit
l Actual balance total out
l Date the account was first overdrawn
l Date the last movement occurred on the account
l Overdrawn excess narrative
l Moved Narrative
The application is updated during the Close of Business after the account or limit goes into excess.

Overdraft Ageing
The following set of fields contains information that is used during the overdraft ageing process for retail accounts, if configured in the Property
Class for Limit.
l CURR.OD.STATUS
l CURR.OD.START.DATE
l CURR.OD.DAYS
l OVERDRAWN.AMT
l THRESHOLD.AMT
l OD.FEE.DATE
When the current overdraft is cleared or the balance is returned under the tolerance amount, the ACCOUNT.OVERDRAWN record is written to
the ACCOUNT.OVERDRAWN.HIST table.
Overdraft Ageing
The following set of fields contains information that is used during the overdraft ageing process for retail accounts, if configured in the Property
Class for Limit.
l CURR.OD.STATUS
l CURR.OD.START.DATE
l CURR.OD.DAYS
l OVERDRAWN.AMT
l THRESHOLD.AMT
l OD.FEE.DATE
When the current overdraft is cleared or the balance is returned under the tolerance amount, the ACCOUNT.OVERDRAWN record is written to
the ACCOUNT.OVERDRAWN.HIST table.
Example – Account Overdrawn with Overdraft ageing details
The following example shows an Account overdrawn record, where the account is subject to overdraft ageing.
This account went overdrawn on the 22 April and the Current overdraft status is 'OD1'. An overdraft fee was taken when the account went into
excess.

If the account remains in overdraft, it will progress through the aging status, depending on the configuration. It is possible to see from the next
screen shot that the account remains in overdraft. The Overdraft status is updated along with the date when it changed.

ACCT.OD.HIST
This internal file is used to record the following overdraft ageing details for accounts:
l Year
l Number of overdrafts in the period
l Total number of days in overdraft, in the period
l For a specific period of overdraft:
o The number of days, the account was in overdraft
o The start date of the overdraft
o The end date of the overdraft
o ID to the ACCOUNT.OVERDRAWN.HIST record
This file can be used to enquire on the accounts overdrawn history details.

Enquiries and Reports Overview

Non Stop Processing Overview
If the Non-Stop Processing Facility is installed on your system, the following applications have been made compatible. Refer to the Non Stop
User guide for additional information:
l ACCOUNT
l ACCOUNT.STATEMENT
l ACCOUNT.CLOSURE
l ACCOUNT.DEBIT.LIMIT

Accounts - User Guide: Release R15.000

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Accounts - User Guide: Release R15.000

Uploaded by

Copyright:

Available Formats

Accounts - User Guide

©2015 Temenos Headquarters SA - all rights reserved.

Accounts - User Guide - Release R15.000 - Page 2 of 207

Accounts - User Guide - Release R15.000 - Page 3 of 207

Accounts - User Guide - Release R15.000 - Page 4 of 207

Purpose of this Guide

Accounts - User Guide - Release R15.000 - Page 5 of 207

Refer to these user guides for further details:

l Calculation of interest on client accounts.

Accounts - User Guide - Release R15.000 - Page 6 of 207

The following pages will address:

Accounts - User Guide - Release R15.000 - Page 7 of 207

l Number of days forward for cash-flow processing.

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

Accounts - User Guide - Release R15.000 - Page 8 of 207

This field will accept the following options:

Accounts - User Guide - Release R15.000 - Page 9 of 207

Accounts - User Guide - Release R15.000 - Page 10 of 207

Accounts - User Guide - Release R15.000 - Page 11 of 207

Accounts - User Guide - Release R15.000 - Page 12 of 207

Accounts - User Guide - Release R15.000 - Page 13 of 207

Accounts - User Guide - Release R15.000 - Page 15 of 207

The following types of account can be entered in T24:

Accounts - User Guide - Release R15.000 - Page 18 of 207

The processing options available on client accounts include:

Accounts - User Guide - Release R15.000 - Page 19 of 207

An example of a simple current account is shown:

Accounts - User Guide - Release R15.000 - Page 20 of 207

Posting Restrictions at Account Closure

Accounts - User Guide - Release R15.000 - Page 21 of 207

Accounts - User Guide - Release R15.000 - Page 22 of 207

Accounts - User Guide - Release R15.000 - Page 23 of 207

Accounts - User Guide - Release R15.000 - Page 24 of 207

The following records are among those permitted:

Accounts - User Guide - Release R15.000 - Page 25 of 207

VOSTRO Identifies a Vostro account

BRANCH Identifies an account belonging to a branch of company processed

BANK Identifies an account belonging to a bank

MORTGAGE Identifies a Mortgage account

MGDEPOSIT Identifies a Mortgage Deposit account

SAVINGS Identifies an account as a Savings account

For accounts, the following IDs are valid.

SUSPENSE DATA.CAPTURE, which have not been authorised.

DIFFERENCE DATA.CAPTURE entries to balance a batch.

NETTING Suspense account for net payments.

SUSPSCDR Suspense account, which the Securities module will use.

SUSPFRACR Suspense account which the FRA.DEAL module will use

Accounts - User Guide - Release R15.000 - Page 26 of 207

PLCLOSE Used at year end closing of PL

INTERCO Used for passing entries between inter-company accounts

ACCOUNT' ACCOUNT.CLASS records

Accounts - User Guide - Release R15.000 - Page 27 of 207

l Client account number format

Accounts - User Guide - Release R15.000 - Page 28 of 207

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.

'@routine Where a local subroutine performs the check digit calculation.

'blank' in all other cases.

Accounts - User Guide - Release R15.000 - Page 29 of 207

Accounts - User Guide - Release R15.000 - Page 30 of 207

In a Multi-Book environment the simple internal account number format is CCYCCCCCNNNNBBBB