T24 Navigation and Environment

T24 Navigation and Environment 1

T24 consists of the code base- which is the code for applications and services.
Enquiries, versions and Menus are built for different roles in a bank and the
configuration is created for a model bank with best practice processes based on our
experience in implementations.

Model Bank is currently packaged with Pre-configured products and processes in
Retail, Wealth, Corporate, Payments and Treasury business domains. The objective
of Model Bank is to reduce implementation effort, by building a robust set of Products
and Processes which can be delivered out of the box.
This is supported with a good Reference System to enable Pre-Sales to demonstrate
Model Bank to prospects and Sales Collateral in the form of Model Bank Reference
Documentation for Sales/Pre-Sales to assure the prospect of the maturity and
completeness of the Model Bank solution.
T24 system with the following
System Parameters
Customized Screens, Reports, Home Pages, Internet Banking Pages
Products
Static Data - Customer, Brokers, Counterparties Banks/Agents
Financial data - Accounts, Deposits, Loans, Portfolios
Populated with transactions across all Products to feature the different
functionalities
Enquiries/Reports pre-populated with data
Home Pages with attractive dashboard
Model Bank business Domains
Retail
Private
Wealth

Corporate
Payments and Treasury

Enter your Username and Password to login to T24

This is the home page that you see as soon as you log in to browser. We will soon see
how we can customize the home page & the menus without writing a single line of
code !!!!!!!!!!!

There are various methods of opening a record in T24.
1. The first method to input a new record is by typing the <Application name>
followed by a space and the function for input- I , followed by another space and
the keys F3 in the command line.
2. The most frequently used method to input a new record is to click on the new deal
icon when the application is launched. In this illustration you have launched the
CUSTOMER application and a new customer can be input by clicking the new
deal icon.
3. you are working in a classic mode then type in the application name, then the
function followed by Ctrl+F+Enter . This opens a new record for the application

When an application is opened, the user can input the ID and use any of the buttons
depending on the function to be invoked, viz Edit, View and Action
button(interchangeable referred to as function or operation).
EDIT Button - - Opens a new record for input or an existing record for ammendment
ACTION Button - Opens a record with Authorise, Delete, Reverse & Verify operations
enabled
VIEW Button - Opens a record in See mode
This is an alternative method to giving the function along with the application and ID in
the command line of the first screen.

What we see here is a sample record in the customer application. The application
name and the record Id( Customer number), is displayed. Customer application is a
form where the details of a customer are filled. The various buttons that are used to
take action on the record is illustrated.
The VALIDATE button is used to validate the data entered in the fields on the form.
Incorrect and erroneous information will not be stored in the database.
The COMMIT button will commit the record and save the contents of the record into
the corresponding database table.
The HOLD button is useful, when the user does not want to commit the data entered
into the database, but at the same time does not want to lose the information input.
The data input is saved to be modified, committed or discarded later as per the users
discretion.
The next set of buttons are Functions enabled on using the ACTION button for an
existing record ID. For a NEW record these will be disabled.
In T24, DELETE function is used to delete an unauthorized record. T24 will never re-
generate the ID of such a record. Once generated the ID is never re-used unless
manually input by the user.
The AUTHORISE function is to be used to authorise the commited record. An
authorizer should be different from the user who has input the record.
Any record which has been authorized cannot be deleted and can be removed from
the live files only by using the REVERSE function. This moves the record to history.
The button which looks like the NEXT button in the record screen is used to verify a
record. This is applicable only for certain transactions.

In FOREX and MONEY.MARKET applications, deals are done at times also through brokers
orally. When the written confirmations are later received, verify function is used to record time
and date of receipt of confirmation.
The Up arrow button helps user to return to application or the previous screen.

For additional information on any of the fields in an application, click on the Field
Label. It opens an online helptext.
The button with the letter i is useful to invoke context sensitive enquiry which is
predefined in the system. For example you may view additional information of the
related customer 100295 shown in the grab, without leaving this window, by clicking
on the Context Enquiry. Output shown on screen.
One significant and important feature in T24 is called multi value and sub value
facility. When a field requires to hold multiple data it can be dynamically expanded or
deleted during transaction input stage.
For example, a customer may have accounts in different currencies and may want his
name to be displayed in the regional language of that currency. To facilitate this,
multivalue the Name field as shown. Sub-value is a second level of doing this. For
example a customer may have an office address and a residence address that you
want to store. You Multi-value the Address field. If each the office address needs to
be stored in multiple languages, then sub-value the address field.

1. When you enter data into a form in T24, you must first validate the data before
storing it in the database. The validate button on the form facilitates this. On
clicking the validate button after data input, it can result in 2 possible outputs
Errors or no errors.
On clicking the commit button, the validations are executed again before the record is
stored in the database.

Error Messages: Such type of messages are displayed -
Due to data not being input in mandatory fields
Due to incorrect data input
Due to incorrect relationship between field name and the data that is input.
In case of Error Messages, you need to correct the data input in the particular fields
and commit the transaction again.
A record is not saved till all errors are corrected.

Once the Errors are rectified, click on the COMMIT button. The outcome of this action
may result in overrides getting generated or no overrides. Overrides are warnings that
get generated on committing a record in T24. You have to accept the overrides to save
the record in the database as an unauthorised record. On clicking the commit button,
the validations are executed again before the record is stored in the database.

An override in T24 is required in a situation where the user needs to be warned that he
has to confirm the action which he would be performing.
For example, A customer wants to withdraw $100 from his savings account which has
a balance of $150. Assume that by T24 norms, the minimum balance in the savings
account should be $100. Now if you input the transaction to debit $100, when
committing it T24 must warn you about the insufficient funds available. T24 cannot
stop you, but it can warn you. T24 generates an override to do this. You will have only
two options, to accept it and complete the transaction or reject it and stop.
1.2 Override Messages: These are warning messages, at least most of the time. A
user may accept or reject override. If accepted, T24 saves the record and the override
message is stored as part of it in the field OVERRIDE. If you do not want to accept the
Override, you may either put the record on hold to correct it later or amend the record
and commit it again.

1. Override is the name of the field which stores the override messages generated
on committing the record.
1.1 This field is part of almost all the applications in T24.
1.2 It is a no input field and updated by T24.

The account created earlier is debited in this FUNDS TRANSFER transaction. The
override message is displayed and you can accept it. The record is now committed.

Now that we know how to navigate, let us see what a T24 environment is. Let us take
training room as an example. What do you see around you?

Similar to a training room, T24 also needs an environment / infrastructure for it to be
put in to use as a software. The users, Branch, date, menus is what the environment
comprises . We will soon see how we can customize our home page, according to
the role

Go to role based home page in the T24 menu and check out the home pages
customized according to role of the bank employees . Shown here is a sample home
page for a teller and the environment he works in .

When a user or a set of users belonging to the same group login, What do they
require?
Every user belongs to a branch or many branches( in case of a bank having many
branches) . They use core T24 applications, user defined screens , functions to access
them , fields to input data , workflows in which many applications are inter linked
logically and enquiries to view reports . We will have a detailed look at the components
in T24 environment in the next few slides.

1. Every bank user who needs login and to perform any action in T24 needs to have
a profile or in other words a record in USER application.
2. Rights and privileges for a user are defined in his user profile . For example,
access given only to FUNDS TRANSFER and CUSTOMER application and also
restrict the access only to Input and List functions.
3. The user profile is a record in the USER application

COMPANY table holds one record per company created in the installation.
The company record will hold the mnemonic which is used as the database file prefix.
The ID of a record in the COMPANY table is referred to as the company code in T24.
The format is CCGGGLLLL Where: CC is Country Code GGG is Company Group
Code and LLLL is Local Code. For example GB-001-0001

LOCAL COUNTRY : This field holds the country code where the company is situated.
LOCAL REGION : This field identifies the region in the country in which the company
is physically situated.
LOCAL CURRENCY : This field holds the local currency of the company.
The Bank may restrict the access of applications to different companies. A company
may access only a set of applications. The applications to be accessed by the
company have to be set in the APPLICATIONS field. APPLICATIONS : This field holds
the various applications that are installed in the company. Different companies of a
bank may have different set of applications installed.
FINANCIAL YEAR END : This field holds the current financial year end date and the
frequency from there on.
Sharing of files among different branches can also be set in COMPANY application
T24 Navigation and Environment

This illustration shows how files are shared by different branches based on what
information they hold customer related or financial data or installation parameters.
Customer and collateral are cus type of files . A branch may opt to share it with other
branches or have its own data. Financial tables like ACCOUNT and FOREX are not
shared among branches. Each branch maintains its own data and is confidential.
Installation files like Dates, SPF only hold information that can be commonly used
across branches and hence shared by all branches.

As shown in the illustration, the Financial files are not shared. Files of type FIN are
exclusively maintained for each Branch. Installation files are always shared by all the
branches of the bank. As represented in the figure, there is only one set of the files
whose type is INT, shared by all branches. Customer files can be configured to be
shared between branches or Not shared. As shown Branch 1 and Branch 2 share the
files with type = CUS, whereas branch 3 has its own copy of Customer files. Like CUS
types, the FIN type files can also be configured to be shared between some branches
and exclusive for some. Where can these configurations be defined? In the
COMPANY record for the Branch.

1. CUS type of files store customer related details.
2. These files can be shared by companies or each company can have its own file.
3. Syntax of the file name would be F<MNEMONIC>.<APPLICATION>. For
example, FBNK.CUSTOMER
4. FIN type of files or applications stores the financial information related to a
company.
5. FIN files are not shared. Financial information as a practice is stored company
wise. Financial information is crucial in deciding the health of the Bank and its
branches and thus is stored company wise.
6. As these files are company specific, the mnemonic of the company is a part of the
file name to identify to which company the files belong to.
7. Syntax of the file name would be F<MNEMONIC>.<APPLICATION>. For
example, FBNK.ACCOUNT
8. INT type of files or applications are specific to one T24 installation.
9. Such type of files are not company specific and have only one file in the first Lead
Company irrespective of the number of branches in an installation.
10. All the other Lead and Branch companies can access these type of files.
11. As these files are installation specific, the company mnemonic is not part of the file
name. The syntax is F.<APPLICATION>.
For example, F.SPF, F.COMPANY are some INT type of files.

1. Applications in T24 are broadly classified into three types OF CLASSES INT, CUS
and FIN. There are other sub-types too, but are not in the scope of this learning unit.
1.1 INT Application Files, which are usually parameter tables or static tables that are
common to all companies in the installation fall under this category. For example SPF,
PROTOCOL, COMPANY etc where only one file exists at database level regardless of
the number of companies.
1.2 FIN Application files store financial data. For example ACCOUNT,
LD.LOANS.AND.DEPOSITS etc. Financial information is always stored specific to a
particular company. Thus these type of applications will require multiple files at
database level depending on the number of companies.
1.3 CUS Application files store customer related information. T24 gives the bank two
options of storing this type of data. The first option being similar to the INT type where
there will only be one file at database level irrespective of the number of companies if
the data is to be shared among the companies or multiple files at database level to
store company specific data if data is not shared between companies.
2. The FILE.CONTROL application contains data about which classification an

application falls under.

1. T24 maintains and uses its own dates. DATES table is used to define the run dates
for the previous, the current and the next working day.
2. T24 does not consider the system date but its own date from the DATES table.
3. The DATES table need not be manually updated to change the current working day.
Dates are rolled forward automatically during the Close Of Business process.
4. All Companies defined in T24 will have a record in DATES table.
5. DATES is an INT type of file and therefore the file name at database level is
F.DATES.
Holidays are stored in another table, which will be discussed as we proceed
However some applications consider the system date. For example, in the USER
application START DATE PROFILE field takes into consideration the computer date
and not T24 date.

The DATES table is used to store the previous, the current and the next working day.
When the dates are rolled forward, only working days are considered.
The ID of a record in DATES table is the Company code.

TODAY : This field denotes the current T24 date.
LAST WORKING DAY : This field holds the date of the previous working day before
COB was run.
NEXT WORKING DAY : This field holds the date of the next working day with respect
to today.
The values in the above 3 fields will be updated during COB.
Values for these fields are populated during Close of Business after referring to the
HOLIDAY table(To be discussed next).
Every transaction in T24 will contain a Value Date which refers to the date on which
the transaction will affect the banks books of accounts. Some T24 modules support a
backward or a forward value date. The maximum back value and forward value
possible is stored here.
BACK VALUE MINIMUM : This field specifies the minimum back value date for a
transaction.
BACK VALUE MAXIMUM : This field specifies the maximum back value date.
FORWARD VALUE MINIMUM : This field specifies the minimum forward value date.
FORWARD VALUE MAXIMUM : This field specifies the maximum forward value date.

VERSION, LOCAL PAYMENT DAY and LOCAL DISPO DAY fields are reserved for future use
and are not used currently.

1. The purpose of the HOLIDAY table is to indicate the public holidays for each
Country, or Region within a Country.
2. HOLIDAY is an INT type of file and therefore the file name at database level is
F.HOLIDAY.
3. This table is referred during COB to determine T24s next working day.
4. This table is also referred by T24 to check for holidays and weekend days when
dates are input in any transaction.
5. The ID of a record in this table is in the format <CountryCode RegionCode Year>.
For example GB 00 2010, AT 00 1988, etc..
Even before you set up a record in the HOLIDAY application, the REGION and
COUNTRY tables must be set up since they are part of the record ID.

To set a particular day as a holiday in a month, the following fields are used
JANUARY DECEMBER : These fields hold the days that need to be declared as
holidays in the respective months. Valid values are 01 until 31 (if applicable). Space is
the delimiter.
WEEKEND DAYS : This is a Multi value field that is used to define the days that are
weekends. Valid input will be any of the days from Monday to Sunday
MTH 01 TABLE - MTH 12 TABLE : These fields are no input fields. These are
populated based on values in fields JANUARY - DECEMBER, WEEKEND DAYS and
WRK WKND JANUARY - WRK WEEKEND DECEMBER. This field can hold H W X as
values. H stands for Holiday, W stands for Working day and X stands for No more
days in the month.
WRK WKND JANUARY - WRK WEEKEND DECEMBER : These fields holds the days
which are actually weekend days but to be declared as working days for each month.
Valid values are 01 to 31 (if applicable)
It is not possible in T24 to declare Current day and the next day as holidays. T24
needs at least one day time to declare a working day as a holiday. For example, if
today is 9th Jan and tomorrow is 10th Jan, you cannot set both 9th and 10th as
holidays in T24. On 9th Jan you can only set 11th Jan and above days as holidays.
If there is any unforeseen situation and you have to declare a holiday during the
middle of the day on 9th Jan, then the Administrator should run COB for 9th Jan before
closing so that the dates are rolled over to 10th Jan which is the next working day.
If there is a situation that you have to set 10th Jan as a holiday on 9th Jan, then the
Administrator has to run COB both for 9th Jan and 10th Jan so that the dates are
rolled over to 11th Jan which is the next working day. Running COB back to back
blindly may not solve this issue. Certain applications may require local development. If
transactions come in through interfaces or ATMs on the physical 10th Jan, they will be
taken as transactions for 11th Jan only as T24 date has already been rolled forward.

In typical situations, COB can also be run remotely by an Administrator.

1. True
2. False Errors must be corrected. Record cannot be committed otherwise
3. True
4. False Holiday table
5. True
6. False - FIN files are not shared since they contain Financial information specific to
one company only.


T24 Navigation and Environment

Uploaded by

Document Information

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

T24 Navigation and Environment

Uploaded by

Copyright:

Available Formats

T24 Navigation and Environment 1