t24 overview - r11.1

1

T1TOL – Overview - R10.1

2

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


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

T1TOL – Overview - R10.1 2

3

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.


4

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.


5

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.


6

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,


besides department wise.


7

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,


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


8

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.


All these groups are differentiated by using suitable CATEGORY code.


9

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.


10

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


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


11

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.


12

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.


13

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.


14

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.


15

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”.


16

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.


17

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.


18

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.


19

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


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


20

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.


21

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.


22

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.


23

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.


24

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.


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


25

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.


26

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.


27

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.


28

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.


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


processed directly from any interfaced channel.


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.


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.


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.


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.


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


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)


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.


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


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.


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.


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.


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.


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 .


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.


43

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.


44

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.


45

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.


46


t24 overview - r11.1

Documents