T1TOL – Overview - R10.

1 1
 Temenos T24 draws upon rich functional features that have been developed
over the years. It is an end to end solution for banking needs. Within a single
software, besides providing a variety of business features used throughout the
world it also provides relevant accounting, risk checking, controlling,
messaging and currency position updating. Hence, it is a fully integrated
software which can effectively replace a combination of software that many
banks currently depend on for their business needs.
It updates in real time not only business related actions but also connected risk
checking, accounting, messaging and currency positions. Not all actions
should be done on line. Besides dragging the performance, there would also
be avoidable repetitions. Such actions are automatically done as a Batch job.
For instance, interest calculation and application, revaluation and producing
reports, just to name a few.
T24 comes with multi currency facility. All its business applications
automatically have features to use more than one currency in a single
transaction. Proceeds of a USD LD loan can be directly credited into
customer‟s GBP account by LD application without the need of FOREX
application.
There are certain facets which are Core or Central to the software, such as
CUSTOMER, LIMIT, Accounting, Delivery etc. T24 functions only if the
entire Core is in place. Business modules such as FOREX, SECURITIES etc

T1TOL – Overview - R10.1 2

 are optional and banks may procure them based on their business requirements.

T1TOL – Overview - R10.1 2

 Temenos T24 is based on open standards. This means that clients can select
the best vendor or environment to suit their own needs – whether this is low
cost, high performance, volume of transactions, local support or any other
factor.
If this changes in future, they can switch vendor without altering their
investment in TEMENOS T24.
This will provide true longevity to their chosen system.
T24 can run on JBase or on Oracle database or a variety of other database also.
Clients can choose which they are comfortable with.
Large banks have also been concerned about scalability and also resilience of
the software. T24 has been able to address these concerns by an architecture
which provides for multiple application/database servers at various levels.
Additional processing capacity can be added by simply adding more servers.
The architecture also ensures that there is no single point of failure.
Thus, T24 is flexible throughout. A Bank can buy only those business
applications they currently need. As it enters into new fields, for example a
retail ank decides to enter into Private Banking domain also, it can buy the
additional applications and seamlessly continue its operations.
These business philosophies of scalability and flexibility are built into all
facets of T24.

T1TOL – Overview - R10.1 3

 We have an overview of Temenos T24 banking system here.
The Core part of Temenos T24, is the most essential part. It is central to T24.
It comprises Customer related information, Accounting, Risk checking,
Delivery and all other static tables. Besides these, T24 also needs Accounts of
Customers and/or internal accounts to operate.
T24 has several optional modules to process business. Modules have been
indicated above under important business groups like Retail, Treasury,
Corporate, Private Wealth Management and General. But, T24 does not
operate with such pre-set rigidity. The above grouping is only illustrative –
what these segments predominantly need – for instance a Retail Bank may also
need and buy FOREX and FUNDS.TRANSFER.
Security Management System over encompasses the core and optional
modules. It takes care of the operational security measures and control of
entering the System, restricting access only to allowed sections and allowing
to do only permitted functions.
With the help of general utilities T24 is presented to end user through versions
or screens. There can be multiple versions of the same application meant for
different users. For example, end users of Front, Middle and Back offices of
FOREX application would need to fill in or view different fields. Instead of
presenting a uniform screen for all of them, three different versions of this
application are built and relevant version is provided to the respective user.
Enquiries can be designed to give desired on line information.

T1TOL – Overview - R10.1 4

 Presentation layer enables T24 to receive input from various sources such as Browser,
Interfaces like an ATM interface, java programs, or from any other third party
software.
Connectivity Layer is where the Web Servers are installed. Apache Tomcat, IBM
Websphere, Oracle Application Server are web servers supported by T24. This server
is used to publish web pages on to Internet Explorer. T24 Browser component and the
Temenos Connector Client are deployed on these web servers.
Network Dispatcher is a third party software used for load balancing. It receives
messages from IE or any other source of input and routes it to any one of the available
web servers. It will maintain the request that it receives in a queue and send it to any
one of the available T24 application servers. The same logic applies to the responses
as well. One of the commonly used load balancers is IBM‟s MQ.
T24 Server: Each of these servers will contain a separate T24 (without bnk.data
directory), JBASE, OFS and Temenos Connector Server installations. TC Server is the
entry point for requests into T24. T24 Server holds all the business logic and
validation of data happens here.
Database Server: T24 is database independent, and supports different databases,
including Oracle and DB2. This server holds database. T24 data resides here in XML
format. Oracle/DB2 databases support clustering and therefore a single Oracle/DB2
installation can be done across multiple servers.
J4 does not support clustering and therefore only one database server can be used if J4
is to be used as a database.

T1TOL – Overview - R10.1 5

 In a Bank, everything revolves around its customers. Similarly, all business
applications make use of the static information of a customer.
Product centric software store information based on their products and hence
have to maintain various details banking product wise, like address for
communication, just to name one. T24 works on centralised Customer details.
All descriptive details of a Customer are stored only in CUSTOMER
application. Every business product takes the requisite Customer information
from here. Thus, if we need information on loans given industry wise, it is not
necessary to have industry wise classification at loan level. It is possible to
pick out the Customer from a loan, find out his industry from his record in
CUSTOMER application and accordingly consolidate loans for a given
industry. The advantage under this system of holding information is easy
maintainability of information. If the Customer‟s industry changes, then it is
adequate if this change is made once in the Customer record. If the Customer
has five accounts and three loans, all of them would get automatically re-
grouped based on industry.
Preferential condition setting can also be easily based on Customer level
information. All accounting entries automatically indicate the Customer
involved in the transaction, if any. In other cases, where no particular
Customer is involved, they mention the department information. Thus, if need
be, it is very easy to even find Customer wise, income and expenditure,

T1TOL – Overview - R10.1 6

 besides department wise.

T1TOL – Overview - R10.1 6

 The CUSTOMER Application contains basic information relating to any
Customer with whom the Bank has dealings.
It is central or Core to the system. All management information, services are
organised around Customer record.
Many Banks formulate rules for preferential treatment based on attributes of
their Customers. AAA rated customers, High net worth clients, Senior
citizens, Export oriented units are some examples of how Banks of different
countries differentiate their customers for preferential treatment in interest
rates or concessions on charges or frequency of sending statements. T24
enables such grouping based on Customer attributes. This will work
effectively if and only if there is only one record for each customer. Further,
this will also make it easy for maintaining customer information.
A Bank may like to report profits from export units and others separately. If
the status of a Customer changes from export oriented units to normal, it is
adequate if this change is recorded in CUSTOMER. Income from all the loans
given to this Customer would henceforth be automatically re-classified.
The CUSTOMER Application contains all the descriptive and non financial
information about any entity with whom the Bank has dealings with. It need
not be a Customer in the conventional sense of the word. In this sense, a
customer base record will need to be opened for correspondent banks, brokers,

T1TOL – Overview - R10.1 7

 guarantors etc., as well as for current and savings account holders.

T1TOL – Overview - R10.1 7

 One of the important aspects of T24 is that all dealings with customers are
classified either as „Accounts‟ or „Contracts‟.
The main difference between an Account and a Contract is that an Account
permits balance to be debit or credit from time to time, whereas in any
particular contract, while the balance may change from time to time, its sign
will not change from the original – viz., debit will not be allowed to become
credit and credit into debit. At the end of the contract, the balance only
becomes NIL.
Customers have different types of Accounts such as, Current Accounts,
Savings Accounts, Margin Accounts and so on. We also have internal
accounts, which are bank‟s own accounts that maintain “base” information not
held anywhere else in the system, e.g.. Cash, Capital & Reserves, Furniture,
Departmental and other Suspense Accounts, Tax awaiting Payment etc.
Customers may have Contracts such as, Money Market deals, Securities
contracts, Loan contracts, Letters of Credit, Foreign Exchange deals and so on.
In all these contracts, the initial sign never changes from one to the other sign.
There are also Profit and Loss items (Categories in T24), which are basically
of two types. Firstly, Product related income or expense - Interest on Loans,
Commission on LC, Charges on Current Account etc. The second type is
overheads, which are not product related - Salaries, Rent, Electricity, etc.

T1TOL – Overview - R10.1 8

 All these groups are differentiated by using suitable CATEGORY code.

T1TOL – Overview - R10.1 8

 All transactions create relevant accounting entries across the clients
Accounts/Contracts and for the banks own internal records. Entries are
automatically generated for authorised transactions.
Though entries are generated only after authorisation of transactions, debits to
accounts affect the balances after the input is committed at unauthorized stage
itself. Accounting entries are classified as STMT.ENTRY, CATEG.ENTRY
and RE.CONSOL.SPEC. ENTRY.
Entries affecting Account balances are stored in STMT.ENTRY file by the
system, be it Customer account or Internal account.
Entries affecting P & L heads are stored in CATEG.ENTRY file. In T24, we
do not open accounts for profit and loss heads. Straight from here, the entries
are consolidated into desired Profit and Loss groupings.
All other entries are stored in RE.CONSOL.SPEC.ENTRY. These entries are
of varied nature, but all of them affect only Assets and Liabilities other than
balances in Accounts - Entries affecting contract heads, accrual and
capitalisation, revaluation etc.
Combination of these entries are possible and happen. A loan is given for
$10,000. After adjusting $25 for loan arrangement charges, balance $9,975 is
credited to Customer‟s savings account.
This would result in debit entry of $10,000 as RE.CONSOL.SPEC.ENTRY,
credit entry of $25 as CATEG.ENTRY and credit entry of $9,975 as
STMT.ENTRY.

T1TOL – Overview - R10.1 9

 There is no actual General Ledger accounts in T24 – only `virtual‟ accounts.
Information is held at a group condition level, better called as Key level.
T24 does not require General Ledger accounts, so how does it maintain a
General Ledger system? In T24 the transaction data is used to feed the
General Ledger, this is accomplished by telling T24 how you wish to analyse
the data. One of the first files set-up on implementation is the
CONSOLIDATE. COND, which has just two records viz. ASSET & LIAB and
PROFIT & LOSS.
Here you specify where T24 should search for the required data such as
Industry code, Nationality, and Residence.
Once this file and the application parameters are in place, T24 is ready to
create and maintain a General Ledger.
Thus, each Bank can design its own General Ledger instead of following some
pre-defined General Ledger.
One Bank may like to group its loans based on industry of borrowers while
another Bank may like to group them based on their tenor like Short term,
medium term and long term. A third Bank may like to group them based on
tenor as well as industry, residence and sector of its borrowers.
T24 gives this flexibility under its feature of not having a pre-decided General
Ledger account head. Banks can decide these based on their reporting

T1TOL – Overview - R10.1 10

 requirements. It is their reports which decide the General Ledger groupings.

T1TOL – Overview - R10.1 10

 The financial data resulting from transactions, have been consolidated by the
system according to the selection criterion defined in CONSOLIDATE.COND
file.
The T24 concept does not have General Ledger accounts, but the selection
criterion of CONSOLIDATE.COND enable us also to create desired
groupings. The groupings themselves are chosen based on reporting
requirements.
Instead of the traditional approach of breaking or consolidating General
Ledger headings to produce reports, T24 look at this from the other side. It
helps to produce consolidations based on the reporting requirements. After all,
the GL should serve the purpose for which it is there – to produce meaningful
reports.
A report is designed by choosing the required header and columns. A report
may be a movement type of a report with opening, debit, credit and closing
balances. Alternately, it may be a closing type of report with only the closing
balances. The columns chosen for a report give this shape.
The lines in a report take their value from the consolidations, or part of the
consolidations. For example, a line may be having information of Loans
outstanding to software industry professionals. Alternately, one line may show
the principal outstanding and another may show the accrued interest.

T1TOL – Overview - R10.1 11

 Single Company, Multi Company and Multi Book are three ways in which
financial accounts can be held in T24.
Under Single Company, the entire Bank is considered as one accounting entity.
Customer files as well as all financial files are common. If branch wise
consolidation of accounts is desired, it is achieved by defining individual
branch / accounting entity using DEPT.ACCT.OFFICER. Even then, inter
branch transfers are not automatic and should be handled carefully using
suitable internal accounts
Under Multi Company set-up, each branch or accounting entity is considered
as a separate company. While Customer record is optionally shared, financial
files are unique to each company. Accounts and Contracts are unique to each
company. Local currency for each company could be different from another.
It is possible to opt for automatic inter-company accounting. From Company
one, a User may be allowed to debit account at Company two and credit to
another account of his Company one. The System will then debit account in
Company one and credit inter branch movement account in Company one. In
Company two, it will debit inter branch movement account and credit to
account in Company two.

T1TOL – Overview - R10.1 12

 When a Bank does a transaction with a Customer, it is exposed to different
types of risks – Risk towards an individual or groups of customers; Countries,
Currencies and Commodities.
Setting a limit for a client allows the lender to control exposure to that client
and to monitor its own overall position. For example, before a loan is made to
a customer, a limit must be set up specifying the maximum amount that the
Bank considers prudent to lend that customer. The limit will enable the clients
transactions to be processed without problem provided the transaction falls
within the agreed limit.
The application will also allow clients to draw facilities in different currencies
and will re-calculate the outstanding amounts into the currency of the limit.
Setting up limits also allows a Bank to monitor its exposure to its clients by
product, e.g. Forex and by sub-product, e.g. a limit for spot. The lender can
also monitor its exposure by commodity, e.g. Industry code, or by country or
currency.
A reducing or non-revolving Limit does not have its value restored on
repayment. A non-reducing or revolving limit is always maintained at the
sanctioned levels.

T1TOL – Overview - R10.1 13

 A reducing Limit does not have its value restored when a Transaction is repaid.
Limits given for loans are an example of this type.
A Non-reducing or revolving limit is always maintained at the sanctioned
levels. Limits for overdrafts are an example of this type.
A limit may be fixed or variable. In case of a fixed limit, collateral value is
only for information purpose. Availability of limit is independent of collateral
value.
In case of variable limit, limit availability directly depends on the value of
underlying collateral. If collateral value decreases, the limit available also
decreases. If collateral value increases, the available limit also increases, but
upto a maximum of sanctioned value.
Another feature of limit is with regard to overdraft facility. A customer may
have four accounts. A limit sanctioned to him may be attached to only one of
these or many of these. When the limit is attached to say two accounts, the
cumulative debit balance in these accounts will not be allowed to be more than
the sanctioned limit.
Further, T24 also provides option to net the balances in these two accounts. If
one of these accounts is having a credit balance of say $0.25 million, and if
netting facility is opted, the second account will be allowed to have a debit
balance of upto $1.25 million against a sanctioned limit of $1 million.

T1TOL – Overview - R10.1 14

 Delivery refers to generation of Advices/Messages in T24.
Delivery is an integral part of Core T24 which is closely linked to transactions
input through various modules. Predefined messages/advices generated on
authorisation of transaction and sent to destination without user intervention.
Messages can also be previewed for verification of details and amendments.
The relevant messages are produced as per predefined mapping and
formatting, from the field input in transaction to the pre defined fields/SWIFT
tags. They are sent through appropriate channels viz., Print, SWIFT or Telex.
The channel/mode of delivery can be configured system-wide and up to the
Customer or account level.
However, if any of the set up of address, carrier, mapping or formatting
specifications are incorrect, the message will go into Repair.
Messages in „Repair‟ can be resubmitted after making necessary corrections.
A well mapped and formatted delivery message will be automatically sent to
the delivery channel/interface unless they have been specifically put on
“HOLD”.

T1TOL – Overview - R10.1 15

 Types of advices or messages in T24 serviced through Delivery can be
Statement of accounts, Deal slips and other Delivery advices.
For accounts, Statement of accounts are sent periodically by Print or Swift. At
group level or account level, the periodicity of sending a statement can be
configured, like quarterly, monthly or daily.
For other applications, it is possible to advice the client of a transaction
through Deal slip and/or Delivery advice.
Deal slips are printed and issued across the counter. When a Customer walks
to cash counter and remits cash, he will expect a receipt. Deal slip facility can
be designed to give such receipts.
Many times, transactions happen when the Customer is not physically present
at Bank. Delivery advices are used to communicate such things to Customers.
This could be a debit advice intimating a Customer about debiting his account
as per instructions to remit money elsewhere. It could even be an advice
intimating change in interest rate in a long term mortgage.

T1TOL – Overview - R10.1 16

 The above diagram illustrates the various static tables that are linked to the
CUSTOMER file.
These are maintained through Administrator menu in Model Bank.
COUNTRY table contains static details of each individual Country like
Country Name, Currency Code. This is used to indicate residence and
nationality of a Customer.
DEPT.ACCT.OFFICER table contains the Departmental hierarchy in a Bank.
It can go down upto naming all the Staff individually or stop at Department
level. In a Customer record, the value indicates the Relationship manager.
Whenever there is a business dealing, then the Value from Customer record is
defaulted, unless otherwise organised. This also appears in all accounting
entries so that Departmental Assets and Liabilities or Profits could be
measured.
INDUSTRY table defines the activity or business the customer is involved in.
SECTOR table helps in defining grouping Customers at a top level for several
purposes. This classification can be used for areas not covered by other
classifications. Sectors can be like Private sector, Public Sector, Staff,
Infrastructure sector, Banks and IT sector.
RELATION table is used to specify various types of relation that could exist
between one customer and another.
TARGET table helps group customers for future marketing purposes.

T1TOL – Overview - R10.1 17

 We have seen earlier that the COUNTRY table contains static details of each
Country like Country Name, Currency Code, Business centre, Inflation index
etc. Dummy Country codes may be used for entities that do not have an
official Country code but have a Currency Code, for example, the European
Currency Unit.
HOLIDAY table is used to indicate the public holidays for each Country, or
Region within a Country, for the calendar year over which the bank's current
business is spread. User must indicate, for each Country or Region, the public
holidays and which days of the week make up the weekend.
All T24 Applications refer to this table during input validation to check
whether any date entered by the User is a holiday. If it were, then they raise an
override to accept or not contract events that fall on a Holiday. It is also used
to determine the delivery date, by taking non-working days into consideration.

T1TOL – Overview - R10.1 18

 CURRENCY.PARAM table contains common details for each Currency to
ensure that the same numeric code and no of decimals are used on different
currency files in a multi company environment. Currency name and Interest
basis maybe changed at individual Currency file level. If interest and charge
currencies of an account are to be different from the Account Currency, it will
be possible only if they are equivalent by having the same exchange value.
This rule can be set here. Numeric currency code, an alternate to Currency
code, can only be changed on this file. Once a record has been authorised,
number of decimal places cannot be changed. If two currencies are involved
in a conversion, then the currency with the lowest rank will take preference as
base currency.
It is possible to create different market rates for the same currency - Separate
rates for Notes / Travellers Cheques etc. Upto 99 markets can be indicated in
CURRENCY.MARKET table. Consolidation keys are formed market wise.
Markets beyond 9 will be consolidated with the market type of the first digit –
example 10 with 1.
In FORWARD.RATES table, the Rest periods can be defined either in months,
e.g. 1 month, or in days, e.g. 7 days, 15 days. System adds the SPOT date to
the rest period to get the exact date of the rest period. If the Rest period is
defined in months and the calculated date falls on a non working day, the date
is moved forward to the next working day. If it moves to next month, the

T1TOL – Overview - R10.1 19

 system will instead move to the previous working day in the same month.

T1TOL – Overview - R10.1 19

 In the options specified above the days on the left represents the number of
days basis for multiplying on the top line of the interest calculation. It
represents the numerator.
Days on the right represents Denominator value. It is the basis for dividing on
the bottom line of the interest calculation and represents the number of days in
an year.

T1TOL – Overview - R10.1 20

 Banks use different Floating interest rates for their operations. The bench
mark rates themselves are different, like Base rate, Prime rate, Overnight rate
etc.
BASIC.RATE.TEXT table is used to define these various bench mark rates for
a Bank.
For the same bench mark, interest rates vary from currency to currency and
they change from time to time. To capture both these aspects,
BASIC.INTEREST table is used to define, currency wise rates for the bench
mark rates and it is defined with an effective date.
Once defined here, they are accessed by various Temenos T24 Applications as
and when required. Rather than defining the Interest Rate details on each
transaction or contract record, the underlying BASIC.INTEREST table is
linked to them. For example, if a Loan is to carry Prime rate + 0.5%, Id of
BASIC.INTEREST for Prime rate is indicated in the contract and also the
relevant spread of 0.5%. As and when Prime rate changes in
BASIC.INTEREST, all the underlying loans linked to Prime rate get a new
value from the effective dates indicated in BASIC.INTEREST.
Future dated changes can be made to BASIC.INTEREST. The new rates will
become effective only on reaching this date. Changes with a past date will
have an effect if capitalisation had not taken place.

T1TOL – Overview - R10.1 21

 This table is used for LIBOR type rates, which vary depending on the length of
time and for Bid and Offer purposes.
For Loans and Deposit contracts that are linked to PERIODIC.AUTOMATIC
option, user will define a schedule for rate reviews. At the scheduled dates the
system will refer to this table and automatically pick up the relevant rate and
apply that to the contract until the next review date.
This table maybe automatically updated/interfaced daily with an external feed
such Reuters, or maintained manually by the user.
PERIODIC.INTEREST keys are generated daily by the System. It is possible
to effect changes in rates of dates prior to system date.
As a result, all contracts which had accessed the changed key at an earlier date,
will recalculate interest based on the changed interest rates
PERIODIC.INTEREST will be used by applications such as Foreign Exchange
to default interest rate on Forward contracts using the Interest revaluation
method or the Money Market applications to perform automatic Rollover. It is
also used to check interest rate tolerances, based on pre-set parameters in
Money Market contracts.

T1TOL – Overview - R10.1 22

 Charges applied to an account will vary from Bank to Bank and for different
categories of account.
Charges could be based on transactions, or on any debit exceeding a particular
value, or on the turnover of debit transactions in a period, or on the number of
debit transactions in a period, or similar rules for credit operations or on not
maintaining a minimum balance or on statements or any Government levy.
As a first step, all the charge rules for a Bank are defined in the respective
tables like TRANSACTION.CHARGE, HIGHEST.DEBIT,
TURNOVER.DEBIT, NUMBER.OF.DEBIT, GOVERNMENT.MARGIN,
DEBIT.INT.ADDON, ACCT.STATEMENT.CHARGE,
BALANCE.REQUIREMENT, NUMBER.OF.CREDIT,
TURNOVER.CREDIT and INTEREST.STATEMENT.
Out of these, a combination of charges would be applicable for a group of
accounts. For example, for savings account, the charges could be only on
balance requirement and number of debit transactions. For a current account,
it could be on turnover of debit and turnover of credit.
Hence, as the next step, several charge tariff structures are created in
GENERAL.CHARGE table.
A particular GENERAL.CHARGE record could then be linked to a group of
accounts, say all current accounts or all savings accounts.

T1TOL – Overview - R10.1 23

 Charges and commission for applications other than Accounts is collected by
using FT.COMMISSION.TYPE table.
Banks collect either a flat charge amount irrespective of transaction size or a
variable commission amount. FT.COMMISSION.TYPE can be defined for
both these situations.
If it is a variable commission, a single percentage rate could be uniformly
applied or different percentages can be defined for different Bands of
transaction amounts. Minimum and maximum Commissions can be specified
for each Band or Level together with overall minimum or maximum
commission charges. Overall Minimum percentage of commission to be
recovered can also be set. Commissions in local currency must be entered and
special foreign currency commissions can also be defined.
CALC.TYPE - FLAT, LEVEL and BAND:
Assume a deal of Principal $100,000 where commission is calculated based on
the Principal. The commission type record specifies an applicable rate of 2 per
cent up to 10,000 and 1.50 percent over 10,000.
If Band is specified for all sub value groups, 2 calculations will be performed,
i.e. 2% on 10,000 1.5% on 90,000.
If Level is specified for all sub value groups, 1 calculation will be performed,
i.e.. 1.5% on 100,000.

T1TOL – Overview - R10.1 24

 If Flat is specified, the basic flat Amount will be applied.

T1TOL – Overview - R10.1 24

 The art of Banking lies in differentiating product offerings to different
Customers or groups of Customers.
A same product can be packaged differently for different groups. The elements
of this differentiation could be in interest rates or concessions over standard
charges or frequency in sending statements. Likewise, taxes to Government
may also not be uniform for all.
For example, a Bank has the following product differentiation - Interest rate of
1.75% is payable on all Savings accounts; but Staff will get a concessional rate
of 2% on their savings accounts. This could be classified as two products –
Normal savings account product and Staff savings account product. The
difference in rule has come about based on attribute of its Customer, being a
staff or not.
Hence, for select applications, T24 follows the route of forming groups based
on Customer and/or product attributes and then applying rules or concessions
for these groups. These business areas include Accounts, Funds Transfer,
Letters of Credit and Securities where most of the times concessions are based
on groups of customers.

T1TOL – Overview - R10.1 25

 Security Management System (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
should be allowed and within that Company, which Application or Table
should be allowed, and if a version has been created for that Application or
Table then further restrict it to that Version so that only certain fields could be
allowed or certain fields with pre-defined default values only could be used.
Further level of access could be done through Functions. This decides whether
the User should be allowed to Input or Authorise or See or Copy or Print or
Reverse or Verify etc.
The next level of access is achieved by giving access only to those records that
fulfill some field level rule. Access to Customer records whose residence is
equal to US.
In Banks, generally people working in a department would be given similar
powers. It is possible to set these rules on an individual basis or to form rules
applicable for a group of users and then attach group to different users.
For example, people working in Savings Account department should be
allowed to Access a Version with Field CATEGORY matching 6001 and this
group is called SAVINP. For a particular user, when assigned to work in
Savings Department, instead of defining all these restrictions could be instead
attached to this SAVINP group.

T1TOL – Overview - R10.1 26

 T24 offers a wide range of functional facilities. What is shown above is but a
gist of this reach.
For accounts, if there is credit balance, interest could be calculated on daily,
average or minimum balance. For the same accounts, if there is debit balance,
automatically the choice for interest would be daily, average or maximum
balances.
For Deposits and Loans, mainstay of most of the banks, T24 offers different
applications with different functionalities. Typically, short term deposits and
loans with bullet repayments and automatic roll over facility. Medium term
deposits and loans with facility to draw schedules, regular or zig zag to suit the
counterparty‟s cash flows. Long term loans with steady stream of fixed
amounts of repayment or fixed amounts of principal and variable amounts of
repayment. Besides, it is also possible to have Credit card type of repayments
where only a percentage value of the demand is collected in the beginning and
the balance is scheduled to be collected over a period of time.

T1TOL – Overview - R10.1 27

 FOREX module covers not only the traditional Spot and Forward deals but
also two legged Currency swap involving a Spot and a Forward. Moreover, in
Forward deals, it is possible to indicate Single and multiple rate options
SWAP module supports recording and administration of both Interest Rate
Swaps and Currency Interest Rate Swaps, which are off balance sheet items. It
also supports one-legged contract types, asset or liability, which are essentially
loans or deposits and balance sheet items.
The module supports Plain vanilla interest rate swap, Currency interest rate
swap with or without exchange of principal, Amortising swap, Accreting swap,
Roller-coaster swap and Balloon swap
MISCELLANEOUS.DEALS module is used to issue guarantees as well as
record receipt. It can handle guarantees issued by a Bank solely or on behalf of
other Banks also.

T1TOL – Overview - R10.1 28

 AA module provides a flexible framework to create products in T24. It
provides a component based architecture for building and managing business
products.
Products are assembled from combinations of reusable components. For
example, a Housing loan product may be designed from components like
Customer, Account, Principal Amount, Interest rate, Charges, Principal and
Interest repayment conditions etc. It is quite possible that a Bank may have say
ten interest rate definitions which are used across different types of loans,
deposits and accounts. Hence, if these ten components are created, then they
could be used across any desired product of the Bank.
It is also likely that a Bank may like to set a rule that when it changes
definition of a fixed interest rate, then that should be made applicable only for
new loans and not for existing loans. Then the changes to loan definition are
not tracked for existing arrangements.
AA Lending is designed to handle complex requirements of retail business. It
is possible to set which condition should be allowed to be negotiated by users,
and if need be within what boundaries. For example, it could be set that only
the margin on a floating rate could be negotiated and not the underlying rate,
and it could be negotiated only between 1 and 1.25.
As AA offers account based lending facility, payment and receipts can be

T1TOL – Overview - R10.1 29

 processed directly from any interfaced channel.

T1TOL – Overview - R10.1 29

 On similar lines of AA (Loans), Deposit products are also assembled from
combinations of reusable components
A variety of deposit types exist in AA DEPOSITS module to cater to the needs
of most banks. These types include - Short Term Deposits , Long Term
Deposits , Floating Term Deposits, Fixed Floating Deposits, Special Term
Deposits, Preferential Deposits and Savings Plan. These features were
supported by ALL.IN.ONE (DEPOSITS)module hitherto.

T1TOL – Overview - R10.1 30

 Structured products are hybrid derivative instruments which frequently consist
of a cash element and an optional element. They are extensively used in
Investment banking, which are used to create modified risk/return proprietary
trading position. These structured products have been currently opted by
private banks for managing their client assets portfolio. Banks can create
instruments based on underlying products in this module. Instruments can be
sold to customers and other Banks.
Advantage derived out of this are as under:
1) Capital protection, 2) Opportunities to benefit from falling stock markets
and 3) Higher returns in a low yielding Global Market.
Debit Cards are issued for customer accounts. This is an instrument to draw
money from customer accounts through ATMs and sales outlets. Card record
will contain account number to which the card is issued, date of issue, charges
incurred and expiry date. Card system can phase out usage of cheque books.

T1TOL – Overview - R10.1 31

 AC.CASH.POOL application is used to record rules for transfer of accounts
from one account to another. This product is a fallout of requirement from
Corporate Customers of Banks. This module enables the Bank to support their
Corporate Customers who are into funds management and reduction of
interest cost. This products makes the Customers feel ease in managing their
Cash resources. A number of accounts in various places of the Customer in
T24 Bank can be linked to enable automatic transfer of funds from one
accounts to another. The transfers can be one to one, one to many and many to
one types. The transfer can be effected by accounts to maintain balance or
transfer surplus.
DIRECT.DEBIT application is used to capture Customers‟ Mandate for
debiting their accounts to meet their external and T24 Bank‟s payment
obligations. This can be linked to Mortgage application to effect repayment of
Mortgage contracts. It is also a Corporate Banking product.
The above list is only a gist. All other T24 products cater to stiff and varied
international needs.

T1TOL – Overview - R10.1 32

 Role Based home page has custom set of menus/enquiries required by users to
carry on the day today operations. Home Page will help the User to process
many customer related transactions, view the customer details, input
transactions and view/create opportunities for the customer. The Home Page is
designed to assist the Supervisor in authorising transactions, to view enquiries
and delivery messages.
Menus available for Customer, Accounts, CRM Funds Transfer, Standing
Orders, Direct Debits and bulk Standing Orders.
Components of Home Page is available in the form of tabs, for easy
navigation.
Functionality is provided with essential CRM features for the front end.
The menu can be used for Teller operations and Securities related transactions.
It is one stop access menu for many T24 usages.

T1TOL – Overview - R10.1 33

 R10 Model Bank has the following Role Based Home pages covering all
banking verticals:

Retail Operations has 1) Retail Officer,

2) Retail Supervisor, 3) Teller / Head
Teller, 4) Customer Service Teller and
5) Cheque Collection
Credit Operations has 1) Credit Risk
(Officer & Supervisor), 2) Retail
Lending – AA (Administrator &
Supervisor) and 3) Corporate Lending
– LD & SL (Administrator and

T1TOL – Overview - R10.1 34

 Supervisor)
Corporate Operations has 1) Remittances
(Back Office) and 2) Trade Finance
(Officer & Supervisor)

Treasury Operations has 1) Treasury

Dealer and 2) Treasury Supervisor
Private Operations has 1) Private
Front/Back/Middle, 2) Corporate Actions
and 3) Derivatives (ETD) (Front Office,
Dealer and Back Office)

T1TOL – Overview - R10.1 34

 Alerts for Customers as well as Relationship Managers are available through
SMS, E-Mail or Net Banking for a host of transactions at the option of the
customer.
These are for different types of transactions like Direct Debits, Standing
Orders, stop payment instructions etc.

T1TOL – Overview - R10.1 35

 International Financial Reporting Standards:
According to IAS32 / IFRS7 Banks are required to periodically report the fair
value of all contracts including those measured at amortised cost. However,
value does not need accounting but needs to be reported. Current functionality
in T24 is as below:
Contracts will identify the market rate index used for disclosure
Central Amortised Cost calculator used to periodically calculate Fair Value
Periodically calculate the fair value for disclosure using the market rate and
store the value
Disclosure value is held as an off balance sheet value in the CRB

T1TOL – Overview - R10.1 36

 Under modular architecture, rules are set and maintained individually for each
product or groups of products. To handle Accounts, Mortgages, Consumer
loans and Deposits, product rules and service conditions are defined
individually for each module.
Exceptions are usage of Core tables, which are used by all modules.
If we look at the underlying business of all these modules, they have common
elements like Principal, interest, charges, repayment rules, accounting, limits
etc. It is quite likely that individual products under these modules may use
similar conditions, but under modular architecture, the conditions are
individually defined for each module.
This individual modular approach is followed not only for initial product
definitions, but it also continues for subsequent product servicing involving
maintaining changes to product conditions from time to time.

T1TOL – Overview - R10.1 37

 Under component based Arrangement Architecture, the components used by
all the products are defined and commonly kept for usage. These include term
amount rules, handling repayments, rules for conducting transactions,
periodically changing rules, accounting rules, interest conditions, repayment
schedules, overdue interest conditions, limits, charges, other preference rules,
customer related rules etc.
Retail operations involve major product lines like Lending, Internet Banking,
Deposits, Accounts, Credit cards etc.
There can be several product groups under these lines like Retail loans and
mortgages under the Lending line. Under each product group, there could be
several product families like vehicle loans, staff loans and consumer durable
loans under retail loans group and long and short term mortgages under
mortgage group. Each of the product line would comprise of several
components out of which some would be mandatory for every product under
that and some could be optional. For example, customer, account, term
amount, repayment schedules, payment rules and accounting may be
mandatory for all loans while interest and charges could be optional. For some
staff loans, a Bank may decide to waive them.
The service conditions of components once built, can be used by other lines
also. Internet Banking line may use some or all these components and may
need altogether additional components.

T1TOL – Overview - R10.1 38

 In the traditional model of a Bank, we have a matrix organisation that is
managing lines of business comprised of products, customer segments, support
functions, risk etc. Whilst this is great in terms of managing parts of the
business effectively, it often flies in the face of managing the customer on a
holistic basis – to what extent are the key objectives of each part of the
business aligned to the value propositions for each customer segment?
Different lines of business for support services, channels, products, functions
such as Risk management etc, and yet the area that is not clearly shown in this
model is the Customer.
In terms of the way in which the classical model is deployed in practice, the
position is much more complicated. It is not surprising that the front, middle
and back office is becoming blurred with this matrix organisation approach
and a desire to complete transactions and processes with a one-stop, STP
approach. The traditional way in which Banks and analysts look to software
vendors is therefore changing and we believe that Temenos is in a unique
position to provide an agile and efficient solution to both the classical and
emerging business model that we see in banking today.
At Temenos we tend to look at the business model somewhat differently,
placing the customer at the centre and then aligning the business around that
Customer.

T1TOL – Overview - R10.1 39

 Historically, TEMENOS T24 has provided the layers beyond Orchestration in
what has been traditionally seen as the back office.
However, as a customer centric system with a strong product engine and
workflow capabilities and an inherent multi channel architecture, we could
argue that TEMENOS T24 today offers a number of traditional front office
features.

T1TOL – Overview - R10.1 40

 TEMENOS ARC represents a strategic move to expand and consolidate our
front office capabilities.
ARC will address the core client facing aspects of banking by offering
dedicated delivery facades built on a generic channel delivery interface.
Operational and analytical CRM features will act as the common
communication layer for the client with direct links to product marketing to
maximise cross and up sell opportunities.
An orchestration layer will provide a mechanism for building consistent
workflows across all channels and managing processes and workloads within
the bank .

T1TOL – Overview - R10.1 41

 ARC stands for Acquire, Retain and Cross-sell. It provides the front to back
office functionality to effectively manage the customer relationships and
revenue generation. As ARC is delivered on T24, it makes use of the T24
single customer database available 24x7 to deliver a truly customer centric
solution which does not need the usual data replication associated with
separate front office applications.
ARC is not a separate application or system. The same T24 system
functionality of data, versions and enquiries, is presented through the selected
channel, configured based upon that channel and the rights of the user. A
customer accessing the internet might see the similar screen information to a
Bank‟s call centre operator, driven from the same T24 “version”.
As well as supporting the management of the customer across multiple
channels, ARC also provides the ability to build and manage sales campaigns
based upon sales opportunities that can be generated from T24 data. These
campaigns can be orchestrated using the business process management
capabilities within T24.
As Banks change their business model, pushing what might previously have
been back office activity to the customer self service channel or automated
process, T24 and ARC can support that migration, simply shifting the activity
to the new channel, delivered with the appropriate mask of functionality,
dictated by user and channel.

T1TOL – Overview - R10.1 42

 Every Bank has its own unique needs/requirements from the software. While
Temenos has built a Model Bank, banks would still like to configure the
system to have their own choices of conditions, and hold additional
information.
They would like to have user friendly screens with default conditions and
above all, get their own reports other than the standard enquiries and reports.
Temenos T24 is highly parameter driven and gives the banks a host of choices
across modules. This calls for a project type of implementation out of a
product. Temenos T24 is flexible enough to allow all these. Thus Temenos
T24, though a product, tends to be completely unique at each location.

T1TOL – Overview - R10.1 43

 Model Bank is generic T24 and does not contain local developments. It
suggests a T24 process for each banking operation.
It Contains over
550 Versions
350 Enquiries
50 COB Reports and
100 Deliveries Set-up
Model Bank led approach of implementation cuts down the implementation
time to a great extent.

T1TOL – Overview - R10.1 44

 Any Temenos T24 operation passes through SMS and reaches Core.
Relevant Static Data are used and limits / working balances are checked and
updated before authorisation in case of debits and after authorisation in case of
credits.
The deal is then authorised by a user other than the original initiator. Maker
and Checker concept or Four eyes principle is being used. It is possible to
design to have an additional Authoriser also.
After due authorisation, the respective delivery messages are generated and
required accounting entries generated.
All Batch processes are typically performed during COB (Close of Business)
for generation of reports, effecting accruals, carrying on necessary revaluations
etc.

T1TOL – Overview - R10.1 45

T1TOL – Overview - R10.1 46