1

In this lesson, we will see how applications store data in T24 Transact
We have seen in the previous session that a T24 product is made up of Application,
services, enquiries and versions. An application records the data entered and stores it in
an associated file, field by field
An application is associated with not just one file/table – Up to five files may be associated
with an application in T24
A transaction in T24 can involve multiple stake holders. A transaction is input by a user
and is authorized by his manager. Depending on values in the fields of the transaction -
banks might want more than 1 level of authorization.

To create a record in T24, you need to input all the mandatory fields and then get the
record authorized.
Inputter is the person who inputs data into the fields in a record.
Authorizer is the person who checks the record and authorizes it.
The error message “EB.RTN.SAME.NAME.AUTHORISER/INPUTTER” will be displayed
if the same user tries to input and also authorize the record.
When the USER authorizes the record, the record is MOVED from the unauthorized to
the authorized file.

6
‘A’ is a function which allows the user to authorize a record.
‘D’ is a function which allows the user to delete a record which is not yet authorized. An
authorized record cannot be deleted.
‘E’ function allows the user to list the unauthorized records.
‘I’ function allows the user to input a record in an application.
‘L’ function is used to list live records
‘S’ allows user to only view the records.
‘R’ authorized records cannot be deleted. To remove an authorized record, the function is R –
Reverse
‘H’ – a reversed record can be brought back using the History restore function
‘Q’ – audit . Not available by default
‘V’ – is a special function. Applicable only for some applications.
•Financial transactions , need version control
•We need to store the changes made in every record
•In T24, the current authorized version of a transaction is keptin the Authorised file and older
versions are maintained in a history file.
•Unauthorized transactions are maintained in the unauthorized file.
•The reason for having separate history files is that over a period - this information can be
archived.
•Deleted History file capture records deleted from unauthorized files. This enables preservation
of deleted transactions for audit purposes.

•Input a record in USER application with ID STEVE and commit. The record will be stored in the
unauthorized file.
• When the record is authorised using the A function, the record is moved from the
unauthorised to the Authorised file
Information about the status of the record – is it unauthorized, is it authorized, is
stored in a field called RECORD.STATUS
RECORD.STATUS for unauthorized record is INAU
RECORD.STATUS for an authorized record is BLANK. Authorized records are also called
LIVE records

10
When an authorised record is modified and committed, the authorized record will continue to be
available in the LIVE file. The modified/unauthorized record is available in the unauthorized file
Note - this ID is now available in two file the LIVE file as well as the unauthorised
When the modification is authorized, the previous LIVE record is moved to the history file. The
unauthorized record with the changes will be moved to the LIVE file.

A record can be modified and authorized many times. Hence the ID of the record in the History
file is ID;CURR.NO STEVE;1
CURR.NO is an audit field that indicates how many times the record has been authorized
Authorised records can only be reversed. When an authorized record is reversed, the record is
available in the unauthorized file as the reversal is not yet authorized. The RECORD.STATUS is
now RNAU.
When the reversal is authorized, the record is removed from LIVE and available in the History file.
The status of the record is REVE. As there can be more than one change for the same ID, the ID of
a record in History file is RECORDID;CURR.NO
To restore a record from the History file, use the H function
When H function is applied on a record that’s reversed, the record will be available in
the unauth file and the status will be HNAU, as the history restore of the record is not
authorized
When the History restore is authorized, the record will be available un the authorised
file. It will continue to exist in the History file.

15
Deleted history is not available by default and must be configured if required for an application.
The ID of the record in deleted history is recid;date.and.time EG 150502;19042581549367

Deleted records can be viewed using enquiry VIEW.DELETE.HISTORY

‘V’ is a special function available only in some applications. Performs some action
depending on the application
For e.g. Verify function is used in RECORD.LOCK application to release a lock

17
Launch RECORD.LOCK application. Select the required record using the dropdown and
click on Action button. This will bring up the VERIFY button. Choose VERIFY to unlock
the record.

18
 Financial transactions need version control
 We need to store the changes made in every record
 In T24, the current authorized version of a transaction is kept in the live file and older
versions are maintained in a history file
 The reason for having separate history files is that over a period - this information can be
archived.
 Deleted History file capture records deleted from unauthorized files. This enables
preservation of deleted transactions for audit purposes.
We know that a record passes through many stages – Unauthorized , Live , authorized , history and
many more
The audit field RECORD.STATUS holds the status of a record
For a live record, RECORD.STATUS is blank/Null
Live records cannot be deleted. They can be reversed.
RECORD.STATUS may be one of the following
INAU – Input Not Authorized
INAO – Input Not Authorized due to Overrides
INA2 – Input requires Second Authorizer
RNAU –Reversal Not Authorized
RNA2 – Reversal requires second Authorizer
RNAO -Reversal Not Authorized awaiting Overrides
HNAU –History Not Authorized
IHLD - Input on HOLD.
REVE -Reversed
When a record is committed or authorised, T24 updates the following audit fields. They are no
input fields attached at the end of every record.

RECORD STATUS: Holds the status of the record. Possible values are INAU, IHLD, INAO,
etc.,. If the record is in live file, RECORD.STATUS is Null
CURR NO. : Holds the number of times the record was edited.
INPUTTER : Holds the ID of the user who has inputted the record.
DATE TIME : Based on the COMPANY table, the corresponding audit fields of the transaction
record displays the local zone date and time when USE.LOCAL.TIME is set to YES in SPF
AUTHORISER : Holds the ID of the user who has authorized the record.
CO CODE : Defaults based on current company logged into
DEPT CODE : Defaults to the user’s department code

The two fields below are populated only when a record is audited (Q function)
AUDITOR CODE : Holds the code of the auditor who has reviewed the record.
AUDIT DATE TIME : Holds the audit date and time.
Data which is entered into T24 applications are stored in Files at database level.
At database level these files are broadly classified into Live files, Unauthorized files History files Deleted
History and SIM files.
Live files store only authorized records. The field RECORD.STATUS will be BLANK for records in Live
files.
Unauthorized files ($NAU) store unauthorized records. There are various Record Statuses that can be
associated with records in Unauthorized Files. The Record Statuses are: INAU, INAO, INA2, RNAU,
RNA2, RNAO, HNAU, IHLD
History files ($HIS) store old copies of authorized records. When an authorized record is edited and the
changes authorized, the latest version of the record is stored in the Live file and the old version is moved
to the History file. If an authorized record is reversed and the reversal authorized, that record also moves
from the Live file to the History file. The Record Status of a reversed record is REVE.
Format of the record ID is : <Record ID>;<Sequence Number>
For Example : 100297;4 100724;3
The History file can store any number of amendments of a particular record.
Deleted History Files store unauthorized records which are deleted. The ID format of these records take
the form: <Transaction reference>;<Date and Time in milliseconds>. Audit fields are updated with User
details (who performed the deletion operation) with the corresponding Date and Time. These records can
be viewed only by using the enquiry VIEW.DELETE.HISTORY.
Simulation - $SIM files store records that are generated after simulation. These records are generated by
T24 and hence there will be no audit fields for records in this file

Number of files for an application depends on the TYPE of the APPLICATION in PGM.FILE
TYPE field in PGM.FILE can contain H, U, L. (there are other types also)
H means APPLICATION will have LIVE, $NAU and $HIS files. Can have $DEL if required
U means APPLICATION will have LIVE, $NAU files. Can have $DEL if required
L means APPLICATION will have LIVE file only
D means codeless Dynamic Application

23
Note: DELETE.HISTORY in FILE.CONTROL must be set to ‘YES’ if deleted history needs
to be maintained by T24. can be set to Y for TYPE in PGM.FILE equal to H or U only

Note: SIM.REQD in FILE.CONTROL must be set to ‘YES’ if $SIM file is required

PGM.FILE for ABBREVIATION has type U
ABBREVIATION has LIVE and $NAU files.
Users can input and authorize records. There is no History details stored for
ABBREVIATION as there is no $HIS file

25
All applications do not have all files at the database level. From screenshots above,
we can see that STMT.ENTRY has LIVE file only as PGM.FILE type is T. SIM.REQD is set
as Yes and hence $SIM file is also available for STMT.ENTRY

26
All applications do not have all files at the database level. From screenshots above,
we can see that AA.ACCOUNT.CLOSURE.DETAILS is a type “D” – DYNAMIC CODELESS
application having LIVE, $NAU and $HIS files at the Database level

27
How are the fields displayed in any application? The system reads the
STANDARD.SELECTION file for the corresponding application and populates all the
fields in the application. This file holds the field names, field position, validations, etc.
This is a no input file and is generated automatically by the system. For an application
to have a record in this file, there must be a corresponding FILE.CONTROL record.
The ID of a record in STANDARD.SELECTION is the application name, eg. CUSTOMER,
USER, ACCOUNT.
The fields associated with an application are seen in STANDARD.SELECTION.
D in the field ‘SYS.TYPE’ denotes a core field that holds data.

In the above screenshot, we can see that the fields displayed in the CUSTOMER
record can be seen in the STANDARD.SELECTION record with ID CUSTOMER

29
In this lesson, we saw how applications store data in T24 Core Banking
Quiz – State True or False

1. False - “EB.RTN.SAME.NAME.AUTHORISER/INPUTTER” error message will be

displayed if the same user tries to input and also authorize the record.
2. True
3. False – FILE.CONTROL provides that info
4. False - An application in T24 can have one or more files associated with it at
database level
5. False – It is stored in $NAU file
6. True
32
33