T24 Induction Business - Overview R13 v1.0 Sept 13

T24 Induction Business - Overview
Welcome to the T24 Overview Course
This is the agenda of this course
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
We will start first with Temenos T24 Solution
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.
From the technical perspective, T24 is the most technically advanced

banking system available today.
It has the most advanced and scalable architecture. This gives it an
unprecedented power and opportunity to meet the challenges of today
and the opportunities of tomorrow.
T24 is built on an open architecture, and uses established industry
standards such as HTTP, XML and J2EE. This reduces the risk of
technology obsolescence.
The design of T24 offers multiple application server support offering
horizontal scalability and supporting huge numbers of users with true
non-stop resilience.
T24 is the world's only true 24 by 7 banking system. It eliminates the
need for traditional end of day processing, enabling users and customers
full access to the system at all times.
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
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
T24 is made available to our clients as a T24 Model Bank. It is a layer built on top of the core T24 system .
The T24 Model Bank is an out of the box T24 offering which contains pre-configured set up.
Best practice products and documented business processes are available serving the needs of each banking sector.
Our proven Model-Bank-led implementation approach has cut down implementation time to a great extent.
Some examples of the various pre-configured set up available in Model Bank are:
Configured data values in parameters and conditions and at the same time, providing flexibility for banks selecting
from readily available list of values
More than 6600 Versions providing user friendly screen presentations for end users
Over 4000 Enquiries and 2500 Composite and Tabbed Screens, providing online information about Customers and
their products
150 Close Of Business Reports providing ease of use as well as information for decision makers
More than 150 Delivery Set-up allowing financial institutions to send messages and notifications to customers in
this customer-focused world
Various transaction screens have been pre configured with default field data. This increases productivity and ease
of use for end users
Role Based Home Pages and Dashboards are available in T24 Model Bank providing focused home pages, menus,
composite screens and workflows appropriate for users performing particular roles
Model Bank also offers flexibility to configure essential local reference fields which allows for the capturing of
information unique to the organisation
T24 Model Bank can be implemented straight out of the box or it can be used as a base for further differentiation.
We shall look at the various differentiation and implementation layers in the next page.
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.
10
10
Now we will look at the T24 Components and their Inter-dependencies
11
11
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
12
12
We will now understand what is the Security Management System called

usually SMS
13
13
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.
14
14
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.
15
15
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.
16
16
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.
17
17
And now we will discover the different screen presentations
18
18
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
19
19
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.
20
20
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.
21
21
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.
22
22
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.
23
23
An Enquiry is an online query that is executed to fetch data from the

database and displays results in a user friendly format
24
24
After drilling down from the previous enquiry, the system returned
with more detailed information about the specific customer.
25
25
When we drill down from the specific account, more detailed

information about the account is being displayed
26
26
During Close of Business (COB), system generates a variety of reports
27
27
Here is an example of the COB report
28
28
Finally we will look at an overview of the Core Tables in T24
29
29
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.
30
30
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 subclassification 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.
31
31
The COUNTRY table contains static details of each individual Country such as
the Country Name and the Currency Code.
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.
32
32
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.
33
33
we can indicate the country or region holiday tables to be validated with.

Inclusion of multiple countries and regions is possible.
34
34
T24 checks against these HOLIDAY tables for processing
35
35
In a loan, we can specify what the system needs to do if scheduled event dates falls on a
Holiday. We can choose to:
Move the date backward to the previous working day OR
Move the date forward to the next working day OR
Move the date forward to the next working day, only if it is within the same month. If it
implies crossing to another month, system will automatically move it backwards to the
previous working day within the same month. OR
Do not move the date i.e. use the Calendar date.
Consider the following scenarios where Friday and Monday are working days while
Saturday and Sunday are non working days. There are no other holidays during this
period.
In Scenario A, assume that the repayment due date is on 25th March which is a Sunday
If Backward is used, the system will move the Due Date to the 23rd
If Forward is used, the system will change the Due Date to the 26th
If Forward Same Month is used, the system will forward the Due Date to the 26th
If Calendar is used, the system does not change the Due Date
In Scenario B, assume that the repayment due date is on 31st March which is a Sunday
If Forward Same Month is used, the system will move the Due Date backward to
the 29th instead of forward to 1st Apr. This is because if the system moves the due
date forward, it will cross over to a different month. As such, system will
automatically change its direction by moving backwards.
In Scenario C, assume that the repayment due date falls on 1st April which is a Sunday
If Backward is used, system will change the Due Date to the 30th of the previous
month.
36
36
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.
37
37
We can also set up multiple sets of exchange rates for a currency
38
38
Different currency markets can be defined for different purposes such as

currency trading, over the counter cash transactions and remittance
transactions.
39
39
In T24, there are various interest type options available to create a loan
40
40
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
41
41
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.
42
42
The list of interest basis shown here is not exhaustive. You may refer to the
INTEREST.BASIS table for the full list of selection.
43
43
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.
44
44
DEPT.ACCT.OFFICER is used to define the list of Departments and/or Account

Officers
45
45
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.
46
46
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
47
47
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.
48
48
In this course, we did reviewed some of the key core tables of T24
49
49
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.
50
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!
51

T24 Induction Business - Overview R13 v1.0 Sept 13

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 - Overview R13 v1.0 Sept 13

Uploaded by

Copyright:

Available Formats

T24 Induction Business - Overview

Welcome to the T24 Overview Course