T24 Induction Business Course Overview

T24 Induction Business - Overview
Welcome to the T24 Overview Course
1 1
This is the agenda of this course
2 2
These are the objectives of this course:

Explain what is T24 and T24 Model Bank
Understand the Interdependencies of T24
Learn the various Configurations available in T24
Understand the Core Reference Tables used for AA Lending
3 3
We will start first with Temenos T24 Solution
4 4
T24 is an award winning product from TEMENOS who is the market leading provider of
banking software systems to retail, corporate, universal, private, Islamic, microfinance &
community banks. Headquartered in Geneva, TEMENOS serves over 1,500 financial
institutions in more than 125 countries across the world.
T24 draws upon rich functional features that have been developed over the years. It is an
end to end solution for banking needs as it is a single fully integrated software which can
effectively replace a combination of software systems that many banks currently depend on
for their banking business.
T24 updates in real time not only for business related actions but also the associated risk
checking, accounting, messaging and currency positions.
T24 comes with multi currency facilities. All its business applications supports more than one
currency. For example, proceeds of a USD loan can be directly credited into customers GBP
account without the need of a separate foreign exchange application.
T24 is made up of core support applications such as accounting and risk checking with the
availability of optional business applications. Banks may procure these optional applications
based on their business requirements.
T24 provides a flexible banking platform offering various implementation options. We shall
take a look at these options in a later section.
5 5
T24 can be accessed from a wide range of channels from the back end system
administrative staff to the front end operations people. T24 can be directly accessed using
the Browser or it can be accessed through interfaces with external systems such as IVR or
other 3rd party systems in order to offer an end to end banking solution.
The Security Management System protects 24 by controlling user accesses to the system.
Some examples are permitting only authorised personnel to use T24 and allowing only
certain staff to authorise transactions. We shall revisit Security Management System later in
this course.
Financial institutions can make use of the T24 workflow tool to design user friendly,
sequential or patterned transactional flows reflecting their unique business processes.
As mentioned, T24 has both core applications as well as optional business applications. It
covers a wide range of banking sector needs, that is, the:
Corporate and Wholesale Banking
Retail Banking
Brokerage, Wealth Management and Private Banking
Treasury and Capital Markets
Customer Relationship
And last but not least,
General Support
Within each banking business areas, various modules are available to cater to different needs
and requirements
6 6
T24 can be accessed from a wide range of channels from the back end system
administrative staff to the front end operations people. T24 can be directly accessed using
the Browser or it can be accessed through interfaces with external systems such as IVR or
other 3rd party systems in order to offer an end to end banking solution.
The Security Management System protects 24 by controlling user accesses to the system.
Some examples are permitting only authorised personnel to use T24 and allowing only
certain staff to authorise transactions. We shall revisit Security Management System later in
this course.
Financial institutions can make use of the T24 workflow tool to design user friendly,
sequential or patterned transactional flows reflecting their unique business processes.
As mentioned, T24 has both core applications as well as optional business applications. It
covers a wide range of banking sector needs, that is, the:
Corporate and Wholesale Banking
Retail Banking
Brokerage, Wealth Management and Private Banking
Treasury and Capital Markets
Customer Relationship
And last but not least,
General Support
Within each banking business areas, various modules are available to cater to different needs
and requirements
7 7
As you have learnt earlier, T24 Model Bank is an out of the box layer built upon the Core
T24 system. It contains various pre-configured set up which can be used straight out of
the box or it can be used as a base for implementation.
There are various optional implementation layers which can be built on top of this base
providing flexibility for differentiation.
A regional layer can be built on top of the standard T24 Model Bank system.
The Regional platform will contain common developments for a specific region or a
country, such as regulatory requirements or common practices of that region or country.
The Parameterisation layer allows your organisation to change the default Model Bank
parameter data values to suit your banks business requirements. One example would be
setting up a daily accrual frequency for your system instead of using the default monthly
accrual cycle found in the Model Bank. The Profit and Loss account numbers for income
and expenses can be parameterised based on your organisations accounting policies.
Further configurations can be made to the T24 Model Bank system in the areas such as
screen designs, adding local reference fields to capture additional data as well as
enhancing menus for the ease of use. We shall revisit Configurations in the later part of
this course.
Customisation refers to special functionalities required by your financial institution that

are not available in the T24 system. These are commonly known as developments and
these typically come with a cost.
8 8
Now we will look at the T24 Components and their Inter-dependencies
9 9
As we have seen, T24 contains a wide range of modules.
Within each of these T24 module, there are usually 3 key layers. They are: Parameters, Conditions and Transactions.
In a module, examples of parameters would be setting up interest accrual frequency as well as setting up the accounting rules.
The Conditions layer would typically refer to setting up of preferential conditions for a particular product. For example, product
A would have default values of 5% interest rate and a maximum term of 5 years while product B would have default values of 7%
as the interest rate with a maximum term of 6 months. The Conditions layer is usually an optional layer, depending on the
module.
After setting up the parameters and conditions in a module, transactions such as creating a loan contract, can be performed.
Transactional efficiencies and quality can be achieved through deriving default values and validating them from the Condition
layer. Processing of these transactions would rely on the modules parameter rules too.
T24 Modules do not work alone. They are usually dependent on T24 Core Tables.
These Core Tables provide a centralised source of data references which help ensure consistency and improve productivity. One
good example would be the BASIC.INTEREST table which allows the Bank to store the most updated market variable interest
rate. Instead of modifying interest rates at each affected contract whenever market rate changes, the interest rates of these
contracts can be updated automatically and immediately without manual intervention. This can be achieved by having these
contracts reference their interest rate to this core table.
We have learnt earlier that presentation layer of T24 can be further enhanced through the use of Configuration
These configuration tools include the local reference fields, menus, reports, versions and enquiries.
Another aspect of configuration is the Security Management System, which is also known as SMS
The Security Management System is used to control who has access to T24, when and to what information and facilities. It is
possible to regulate access to the system through various levels. These security management accesses can be configured.
We shall explore Configurations in the upcoming section
10 10
We will now understand what is the Security Management System called usually SMS
11 11
We will now look at an Overview of T24 configurations.
In this section, we will look at Configurations in 2 aspects:
- First, Security Management System

- Second, Screen Presentations (such as versions, menus and local reference fields)
We shall look at Security Management System now.
12 12
The Security Management System (also known as SMS) is used to control who has access to T24, when
and to what information and facilities.
It is possible to regulate access by directing to which Company the User is allowed and within that
Company, which Application or Table is to be permitted.
And if a version has been created for that Application or Table, we can further restrict the access to that
Version so that only certain fields could be allowed or only fields with certain pre-defined default values
could be used.
Further level of access could be done through the type of functions. This decides whether the user should
be allowed to Input, Authorise, View, Copy, Print, Reverse or Verify records.
The next level of access is achieved by granting the user access only to those records that fulfil certain
field level rules. For example, a user is given access to view Customer records only when customers
residence is equal to US.
It is possible to set these permission rules on an individual basis or to form rules for a group or role. One
or multiple groups can be attached to a role which in turn is attached to a USER profile.
For example, people working in Loans department should be allowed to access certain loan transaction
screens. We can form a group called LOANS. When a particular user is assigned to work in this Loans
Department, this user can be attached to this LOANS user group instead of having to define accesses
individually for each user. We can also create a loan user role and link the Loan user group to this. The
loan role will then be attached to the user profile.
There will be more on user Roles in the intermediate and advanced SMS courses.
13 13
When processing transactions in T24, the system may display messages to the user to ensure
that operations are proceeding on the correct line. These are broadly classified as Error
messages and Override messages.
Error messages are displayed due to situations such as mandatory fields have not been
completed, incorrect data, and incorrect relationship between data input in different fields.
Error messages ALWAYS STOP the transaction from being committed for input. Unless the data
is corrected, the transaction cannot continue.
14 14
On the other hand, Overrides messages behave like warning messages.
There are 2 types of overrides in T24. One is non blocking and another is blocking.
By default, all overrides are made to be non blocking in the standard T24 Model Bank. That is,
users can read and accept override messages on their own and then proceed with the
transaction.
For risk management purposes, an Override can optionally be made as a blocking override. This
means that only certain users with the appropriate authority can approve these.
Nevertheless, the audit trail keeps a record of all override messages whether it is a non-
blocking or blocking override.
If it is a blocking override, it will also record the name of the person who has approved it.
15 15
And now we will discover the different screen presentations
16 16
We shall now look at the other aspect of Configuration, that is Screen Presentations.
Screen presentations comprises various elements such as :
Versions
Local Reference Fields
Menus
Enquiries
And Reports
17 17
Here you can see the core ACCOUNT application screen, which represents the complete set of
fields in the ACCOUNT table
The fields of the ACCOUNT application serve a wide range of business needs required of an
account. Some fields are relevant for certain situations but not applicable for others. Some of
these fields are more suitable for back end administrative users or decision makers while only
certain fields are applicable to front end operations staff.
If a front end operations staff is to open an account for a customer using this ACCOUNT
application, this staff member will need to search through all the fields in the application in order
to identify which fields are actually required for input.
As such, it is neither practical nor efficient for an end user to use the core ACCOUNT Application
to create a new account. Instead, versions can be used.
A version is derived from the application screen. We can select the essential fields of the
application to be displayed as well as design other settings such as displaying certain fields as
mandatory or renaming fields for the ease of understanding.
On the next slide we will see two examples of ACCOUNT versions.
18 18
In this slide, we will look at ACCOUNT versions, which was designed using the ACCOUNT
application as the base.
The first example is from the T24 Model Bank. It contains mandatory fields as well as displays
only essential fields required to create an account. Instead of aligning fields one after the other
in the core Application screen, fields can be designed to be more user friendly and to make
better use of screen spaces. In this example, we can see that fields are aligned in a left and right
manner. Fields for similar purpose can be grouped into tabs to improve its usability.
The second example is an enhanced configuration we can make to the T24 Model Bank screens.
In this example, we have created only 4 essential fields to open an account. This minimum set of
displayed fields can improve end users productivity. To further improve efficiency, we can even
create default data values in the fields. For instance, we can default the currency field as the
local currency if most accounts are opened in that manner.
19 19
T24 applications are self-sufficient and generally, provide users with all the necessary fields to
store data pertaining to an application. However, there may be unique situations where Financial
Institutions want to record some extra information which cannot be recorded using existing fields.
To cater to such needs, Local Reference Fields can be created in the particular client environment
to meet their needs without affecting the actual application code.
Local reference fields are configurable.
Once these local fields are created, they can be reused in various applications across T24.
We have learnt about Versions just now. Local reference fields can be incorporated into a Version
and displayed to users.
20 20
Menus can be used to group activities that a user will need to perform. This means that users
do not need to remember application or version names and can easily navigate using menus to
accomplish their tasks.
T24 allows the creation of multiple menus according to each users work profile.
Menus can be further broken down into submenus.
21 21
An Enquiry is an online query that is executed to fetch data from the database and
displays results in a user friendly format
22 22
After drilling down from the previous enquiry, the system returned with more detailed
information about the specific customer.
23 23
When we drill down from the specific account, more detailed information about the
account is being displayed
24 24
During Close of Business (COB), system generates a variety of reports
25 25
Here is an example of the COB report
26 26
Finally we will look at an overview of the Core Tables in T24
27 27
This diagram illustrates some of the key core static tables
As explained previously, these act as Core reference tables. They serve a variety of purposes.
They include:
Providing lists of values to use at the transaction level
Acting as a centralised point of reference and
Providing support for the creation of financial products and transaction processing.
We will explain the use of each table in this section.
28 28
Category codes are used to classify financial transactions on T24 according to the type of
business operation or product. Category codes are also sometimes known as Product codes.
In T24, there are 3 broad key types of categories. They are: Accounts, Contracts and Profit &
Loss. These broad category code ranges have been pre-defined.
The use of these codes, together with Customer characteristics, such as Residence, Status,
Industry and Sector codes etc., can enable your organisation to produce balance sheets and
other financial reports reflecting a coordinated and structured view of your operations.
Category Codes comprises up to 5 digits. The first or first two digits represent the highest level
of classification and the remaining digits represent a sub-classification which provides a clear
definition of the product type or profit & loss.
These are just some of the Model Bank CATEGORY ranges shown here. You may refer to the
CATEGORY table for the full list of category codes.
29 29
The COUNTRY table contains static details of each individual Country such as the Country Name
and the Currency Code. Country Codes are used to define the Residence and Nationality of the
Customer.
Dummy Country codes may also be used for defining entities that do not have an official Country
code but have a Currency Code, for example, EUROPE.
The REGION table is an optional table and is used to segregate a Region within a Country where
the public holidays or non working days differ from other parts of the Country. This enables a
separate HOLIDAY table to be defined for the Region.
In the screenshots here, you can observe that we have set up USA with a country code US. We
can further define various regions for US. For example, US01 for New York and US02 for
California etc.
30 30
HOLIDAY table is used to indicate the public holidays and non working days for each Country, or
Region within a Country, for the calendar year over which the Organisation's current business is
spread across.
All T24 Applications validate against this table during input to check whether the dates entered
are non working days.
In a loan, the HOLIDAY table will be used to check the maturity date, payment due date, and other
scheduled activity dates. If one of these dates falls on a weekend or a holiday, T24 system will
alert the user by generating an Override Message.
31 31
we can indicate the country or region holiday tables to be validated with. Inclusion of multiple
countries and regions is possible.
32 32
T24 checks against these HOLIDAY tables for processing
33 33
In the CURRENCY table, mid rate, buy rate and sell rate can be defined. Depending on the
module set up, the appropriate rate will be defaulted into the transaction contracts. In most
situations, the mid rate will be applied
These exchange rates may be updated manually or electronically via an interface to external
systems such as Bloomberg.
34 34
We can also set up multiple sets of exchange rates for a currency
35 35
Different currency markets can be defined for different purposes such as currency trading,
over the counter cash transactions and remittance transactions.
36 36
In T24, there are various interest type options available to create a loan
37 37
The floating rate fluctuates according to market movement. One common example of floating rate
is the Prime Rate
The BASIC.INTEREST table stores interest rates which are applicable across contracts regardless of
the contract duration
The rates in BASIC.INTEREST table need not necessarily be manually maintained. These rates may
be updated automatically through external feeds
38 38
Unlike the BASIC.INTEREST table, the PERIODIC.INTEREST table provides facilities to store time
based interest rates.
One common example of Periodic Rates is the LIBOR rate.
As you have seen, there are 2 key tables which can help store interest rates in centralised
locations.
The actual usage of BASIC.INTEREST and PERIODIC.INTEREST tables is dependent on each
financial institutions business situation and circumstances.
39 39
The list of interest basis shown here is not exhaustive. You may refer to the INTEREST.BASIS
table for the full list of selection.
40 40
The accrual rule can be selected at the product level or can be made to be selected at the loan
level.
The screenshots here show the standard records from Model Bank. You may create new accrual
rule records by defining appropriate field selections.
41 41
DEPT.ACCT.OFFICER is used to define the list of Departments and/or Account Officers
42 42
There are times when a Financial Institution would like to restrict debits and/or credits posted to
an account. Posting Restrictions can be used for this purpose and can be useful for situations
such as a bankruptcy or when a customer passes away.
The POSTING.RESTRICT table displayed here demonstrates different reasons defined for not
allowing transactions. Restrictions can be made as a full restriction or as a partial restriction. For
example, we can define exceptions such as allowing the posting of bank charges while all other
debit transactions will be restricted.
43 43
In this example, a Posting Restriction of 4 has been defined on a loan, which will generate an
override message to refer the customer to a Supervisor. When a credit transaction is processed,
the system displays the account number followed by Refer Credits to Supervisor
44 44
Posting Restriction codes can be 01-99. You may define codes 01-79 for any description you
would like.
Codes 80-89 are reserved for accounts that are pending to be closed but not ready to be
closed.
Codes 90-99 are reserved for accounts which need to be closed automatically when balances
are zero.
45 45
In this course, we did reviewed some of the key core tables of T24
46 46
During this course, we look at an overview of T24 and T24 Model Bank.
We discovered some of the key configurations and components of T24 as some of the key
core tables.
47
We have now come to the end of this course. We hope that you have attained a high level
understanding of T24 and would like to welcome you to join us in our subsequent courses.
Thank you!
48

T24 Induction Business Course Overview

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

T24 Induction Business Course Overview

Uploaded by

Copyright:

Available Formats

T24 Induction Business - Overview

Welcome to the T24 Overview Course

This is the agenda of this course

These are the objectives of this course:

Understand the Interdependencies of T24

Learn the various Configurations available in T24

Understand the Core Reference Tables used for AA Lending

We will start first with Temenos T24 Solution

Customisation refers to special functionalities required by your financial institution that

Now we will look at the T24 Components and their Inter-dependencies

As we have seen, T24 contains a wide range of modules.

We will now look at an Overview of T24 configurations.

In this section, we will look at Configurations in 2 aspects:

- First, Security Management System

We shall look at Security Management System now.

On the other hand, Overrides messages behave like warning messages.

And now we will discover the different screen presentations

Screen presentations comprises various elements such as :

On the next slide we will see two examples of ACCOUNT versions.

Menus can be further broken down into submenus.

During Close of Business (COB), system generates a variety of reports

Here is an example of the COB report

Finally we will look at an overview of the Core Tables in T24

This diagram illustrates some of the key core static tables

T24 checks against these HOLIDAY tables for processing

We can also set up multiple sets of exchange rates for a currency

DEPT.ACCT.OFFICER is used to define the list of Departments and/or Account Officers

You might also like