Overview on Temenos T24

7/22/2019 Overview on Temenos T24

http://slidepdf.com/reader/full/overview-on-temenos-t24 1/32

T24 Model Bank Introduction (T2MBIN-R5) - Overview 1

Copyright © 2006 TEMENOS HOLDINGS NV

• TEMENOS EDUCATION CENTRE

Warning: This document, is protected by copyright law and international treaties. No part of this

document may be reproduced or transmitted in any form or by any means, electronic or mechanical,for any purpose, without the express written permission of TEMENOS Holdings NV Unauthorized

reproduction or distribution of this presentation or any portion of it, may result in severe civil and

criminal penalties, and will be prosecuted to the maximum extent possible under applicable law.”

Information in this document is subject to change without notice.


Overview of Temenos T24 Model Bank





Temenos T24 Functional features

• Temenos T24 is a product for international financial services

market

• It has comprehensive functions

– Integration

– Timely (both in batch and real time)

– Multi-currency

• It has core functionality

• It has optional Applications

While Temenos T24 boasts of a ‘disruptive technology’, it also draws

upon the rich functional features that have been developed over the

years. This makes it one of the most advanced software products in theworld to meet the needs of the financial services market.

There are certain facets of the software, which are ‘Core’ and which all

banks which wish to use Temenos T24 have to procure. The ‘Core’

includes, among others, applications such as CUSTOMER, ACCOUNT,

LIMIT, the Security management system, various utilities, the

messaging systems (DELIVERY). Most business modules such as

LOANS.AND.DEPOSITS, MORTGAGE, FOREX, SWAPS,

SECURITIES, DERIVATIVES etc are optional and banks may procure

them based on their business requirements.





Open Standards

• Temenos T24 runs on

– Open hardware

• Scalable architecture that permits adding further servers as volumes

expand

– Open user interface through browser, HTML and XSLT

– Open connectivity through XML and Web services

– Open database

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, local support or any other factor.If this changes in the 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 any other database

which the clients 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 multipleapplication/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.





Temenos T24 Functional Architecture

Security Management System

Version Presentation Enquiry

Static Contact History Overview Customer Profitability Preferences and Groups

Trust /PrivateWealth Management

Asset ManagementPerformanceModeling…

Fiduciaries

Fixed deposits

BrokerageOrder processing

Corporate Actions…

Treasury

FX

Swaps

Money Market

FRA

Repos

Capital Markets

Futures/Options

Retail

AccountsDDA, checks, cards,statements, charges,sweeps, direct debits

Mortgages / loans

Teller

Mutual Funds*

Corporate

Trade Finance

Guarantees

Commercial Loans

Cash Management

Syndicated Loans

General

Nostro Recs

Funds Transfer

Confo matching

Euro

PlanningLeasing

Past Due

Intermediary comp

Tax

Bills

Image

Document mgt


CORE

Support Modules

Accounting Risk Delivery

General Ledger

MIS / P rofitability

Limits / Collateral

Market Risk

Swift / FIX

Print / Telex / Other

MC/ MB

Multi Currency

Language,

Dev Toolkit

Programming

Database

Workflow

Exception STP

Dispo

Channel ServicesWeb Call Centre Mobile Browser Web Svcs IVR

We have an overview of the Temenos T24 banking system here.

The Core part of Temenos T24, is the most essential part, around which

the optional modules are built. Security Management System over encompasses the core and optional modules.





Temenos T24 Technical Architecture




Trust /PrivateWealth Management

Asset ManagementPerformanceModeling…

Fiduciaries

Fixed deposits

BrokerageOrder processing

Corporate Actions…

Treasury

FX

Swaps

Money Market

FRA

Repos

Capital Markets

Futures/Options

Retail

AccountsDDA, checks, cards,statements, charges,sweeps, direct debits

Mortgages / loans

Teller

Mutual Funds*

Corporate

Trade Finance

Guarantees

Commercial Loans

Cash Management

Syndicated Loans

General

Nostro Recs

Funds Transfer

Confo matching

Euro

PlanningLeasing

Past Due

Intermediary comp

Tax

Bills

Image

Document mgt


CORE

Support Modules

Accounting Risk Delivery

General Ledger

MIS / Profitability

Limits / Collateral

Market Risk

Swift / FIX


MC/MB

Multi Currency

Language,

Dev Toolkit

Programming

Database

Workflow

Exception STP

Dispo

T24 Server

Channel ServicesWeb Call Centre Mobile Browser Web Svcs IVR

This is the standard T24 architecture that has been used for many

years. It remains unchanged.

T24 Server will hold T24, jBASE, OFS and TEMENOS CONNECTORserver installations. TC Server is the entry point for requests into T24. It

is in the T24 server, that all the business logic is held and the actual

validation of data happens at this server.





P

r e

s e

n

t a

t i o

n

Browser

D

a

t a

b

a

s e

A

p

p

l i c a

t i o

n Presentation

NON-STOP

Presentation Presentation

NON-STOP

S

c

a

l e

S

c

a

l e

S

c

a

l e

S

c

a

l e

C

o

n

n

e

c t i v

i t y

Web Server

Network Dispatcher

GIB Internet Web Services Enterprise Console

MQ

APIsExcel etc.

Other connectivity

X

M

L

Web Server• Apache Tomcat•IBM Webs Sphere•Oracle ApplicationServer

T24 Browsercomponent

Linux, IBM I/Z Series,HP, Unix, Windows

C object code

Oracle, DB2, J4

No batch Non Stop!

Cluster Installation

Multi-channel

API – Java and COM

NO SINGLEPOINT OFFAILURE

Temenos T24 Technical Architecture - Resilience

Load Balancer

Presentation layer enables T24 to receive input from various sources such as Browser,

Interfaces such as 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 Temenos T24.

This server is used to publish web pages on to the Internet Explorer

The T24 Browser component and the Temenos Connector Client are deployed on

these web servers.

The Network Dispatcher is a third party software, used for load balancing. Its job is to

receive messages from IE or any other source of input and route 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.datadirectory), jBASE, OFS and TEMENOS CONNECTOR server installations. TC Server

is the entry point for requests into T24. It is in the T24 server, that all the business

logic is held and the actual validation of data happens at this server.

Database Server : T24 is database independent, and supports different databases,

including Oracle and DB2. It is in this database server that Oracle/DB2/J4 is installed.

This is where the T24 data will reside 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





CORE - CUSTOMER


CORESupport Modules

Accounting

General Ledger

MIS / Profitability

Risk

Limits / CollateralMarket Risk

Delivery

Swift


7Copyright © 2005 TEMENOS HOLDINGS NV

MC/MBMulti Currency

Workflow

Customer centric

All descriptive details of Customer stored centrally

Address, Industry, Sector, Status, Target…

Preferential treatment in products can be set based on Customer grouping

Customer level static changes automatically change consolidation of A/L and P/L

Customer record needed for anyone with whom the Bank deals

More in session on CUSTOMER…

The CUSTOMER Application contains basic information (static data)

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.

The CUSTOMER Application contains all the basic information about

any "Customer“ (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.





CORE – AccountingStatic Contact History Overview Customer Profitability Preferences and Groups

CORE

Support Modules

Accounting

General Ledger

MIS / Profitability

Risk


Delivery

Swift



MC/MBMulti Currency

Workflow

Accounts

01000 - 19999

Contracts

20000 - 49999

Profit & Loss

50000 - 69999

CATEGORY

Interest paid

Interest received

Commission

50000 – 59999

50000 – 50999

51000 – 51999

52000 – 52999

Product related PL

Deposits

Takings

Loans

Placements

21000 – 21999

21001 – 21029

21050 – 21074

21075 – 21084

LD and MM

Sub-blocks range

Salaries

Operating expenses

60000 and above

60000 – 60999

62000 – 62999

Non Product related PL

Not possible to

accrue interest

10000 – 19999

10000 – 10999

11000 – 19999

Internal Accounts

Cash accounts

Fixed Assets, Suspense etc

Possible to accrueinterest01000 - 99991000 - 1999

2000 - 2999

5000 - 5999

6000 - 6999

Customer AccountsCurrent accounts

Vostro accounts

Nostro accounts

Saving accounts

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 an Account permits thebalance 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 become 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,

Premises & Furniture, Departmental and other Suspense Accounts, Tax awaiting

Payment to Authorities etc.

Customers may have Contracts such as, Money Market deals, Securities contracts,Loan contracts, Letters of Credit, Foreign Exchange deals and so on.

It may be observed that in all these contracts, the initial sign never changes to the

other sign

There are also Profit and Loss Accounts (Categories in T24), which are basically of

two types. Firstly, there are ‘Product related’ income or expense. E.g.., Interest on

Loans, Commission on LC, Charges on Current Account etc. The second type of

income/expense is overheads, which are not product related. Salaries, Rent,

Electricity, etc. fall under this group.

All these product groups are differentiated from each other by using suitable

CATEGORY code





CORE – Accounting entriesStatic Contact History Overview Customer Profitability Preferences and Groups

CORE

Support Modules

Accounting

General Ledger

MIS / Profitability

Risk


Delivery

Swift



MC/MBMulti Currency

Workflow

ASSETS & LIABILITIES

STMT.ENTRYEntries affectingAccount balances

RE.CONSOL.

SPEC.ENTRY

Entries affectingall other

Assets & Liabilities

PROFIT & LOSS CATEG.ENTRYEntries affecting

PL Heads

All transactions / contracts create the relevant accounting entries across

the clients accounts and for the banks own internal records. Entries are

automatically generated for authorised transactions. Accountingentries are classified as STMT.ENTRY, CATEG.ENTRY and

RE.CONSOL.SPEC. ENTRY. Combination of these entries are possible

and happen. Though entries are generated only after authorisation of

transactions, debits to accounts affect the balances after the input is

committed (at unauthorised stage itself).

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.

All other entries are stored in RE.CONSOL.SPEC.ENTRY





CORE – General Ledger and other reports


CORE

Support Modules

Accounting

General Ledger

MIS / Profitability

Risk


Delivery

Swift



MC/MBMulti Currency

Workflow

Entries affectingAccount balances

Entries affecting

all other Assets & Liabilities

Entries affecting

PL Heads

STMT.ENTRY

RE.CONSOL.

SPEC.ENTRY

CATEG.ENTRY

ASSETS & LIABILITIES

Key Consolidation based

On Customer and

Application information

PROFIT & LOSS

Key Consolidation based

On Customer and

Application information

REPORT CREATION

HEADER

LINE COLUMN

…………...

…………..…

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

reports, respectively lines.

Before creating lines, we need to create the columns and the header.





CORE – Multi Company (MC) Vs Multi Book (MB)

• Model Bank uses Multi Book

• Features of MB/MC are:

– A financial entity (Branch/Dept) can be opened as Company or

a Book

– Possible to produce independent balanced books at financial

entity level

– Financial reports are automatically created at entity level

– Automatic Inter- Entity accounting at transaction level

– Flexible Consolidated Reporting (entities can be grouped andreported)


CORE

Support Modules

AccountingGeneral Ledger

MIS / Profitability

Risk


Delivery

Swift



MC/MBMulti Currency

Workflow

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 and all financialfiles are common. If branch wise consolidation of accounts is desired, it

is achieved by defining individual branch / accounting entity using

DEPT.ACCT.OFFICER.

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.

Model Bank follows the third approach – Multi Book, where financial

level data is stored in same database, but identified separately usingCOMPANY.CODE field in each Account and Contract. It allows

independent financial entities to produce independent balanced books

while sharing the same financial data files – CUSTOMER and NOSTRO

ACCOUNT

It is relatively simple to move customer accounts and contracts from

one branch to another without closing and reopening them






• Differences between MC & MB (Functionality)

– In MC it is possible to have a different local currency for each

financial entity. In MB, the local currency has to be the same

across all financial entities.

– In MB it is possible to transfer accounts/contracts from one

entity to another. This is not possible in MC.

– MB allows closure and merger of branches

– Foreign Exchange Positions are consolidated for all entities in

MB whereas it will be available only at independent entity level

in MC.


CORE

Support Modules


MIS / Profitability

Risk


Delivery

Swift



MC/MBMulti Currency

Workflow

Customer accounts and contracts can be transferred from one

Company to the other, without actual closure. Their Ids will continue to

be samePossible to transfer select or even all Customer accounts and

contracts to another Company

Inter book accounting automatic

Loan input at HO, and belongs to HO. Proceeds transferred to

Customer’s Current account in USD with Branch 3

Accounting entries automatically passed at H.O

Debit Loan Credit Inter-Branch Account Branch 3: USD-

12800-0011-0001 Accounting entries automatically passed at Branch 3

DR. Inter-Branch Account : HO USD-12800-0001-0011.

CR. Current Account of Customer






• Differences between MC & MB (Architecture)

– In MB Financial level data is held in a single database for all

entities whereas in MC financial level data is held in separate

table for each entity

– In MB financial level data from different entities can be easily

combined. While this is possible in MC, it is less efficient.

– In MB customer accounts do not have to be identified by a

branch code as in MC, so it is possible for all accounts in each

group of branches to follow the same structure.

• Note – It is also possible to use a combination of MB & MC


CORE

Support Modules


MIS / Profitability

Risk


Delivery

Swift



MC/MBMulti Currency

Workflow





CORE – Limits

• In Model Bank, Limits can be established at Customer level and

Customer group level

• Limits can be established at Product and sub product levels

– Multiple limits may be given to a Customer for the same

Product / sub product

• Limits can be optionally made variable, in line with underlying

collateral value

• While attaching Limits to accounts to allow overdrawal, it could

be attached to single or many accounts

• More on session on Limits…


CORE

Support Modules


MIS / Profitability

Risk


Delivery

Swift



Multi BookMulti Currency

Workflow

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 or groups of countries; Currencies; CommoditiesSetting 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 it prudent to lend that customer. The

limit will enable the clients transactions to be processed without

problem providing 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 when

a Transaction is repaid. A Non-reducing or revolving limit is always

maintained at the sanctioned levels.

A limit may be fixed or variable depending upon it being allowed to

change in line with changes in collateral value.





CORE – Delivery

• Delivery refers to generation of Advices/Messages in T24.

• Delivery is an integral part of Core T24 which is closely linked to

the transactions input through various modules.

• Predefined messages/advices generated on authorisation of

transaction are sent to the destination without user intervention.

• The relevant messages produced as per predefined mapping and

formatting (from the field input in transaction to the pre defined

fields/SWIFT tags) are sent through appropriate channels viz Print,

SWIFT etc.

• The channel/ mode (carrier) of delivery can be configured system-

wide and up to the Customer or account level.


CORE

Support Modules


MIS / Profitability

Risk


Delivery

Swift




Workflow





CORE – Delivery

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


CORE

Support Modules


MIS / Profitability

Risk


Delivery

Swift




Workflow





CORE – Delivery


CORE

Support Modules


MIS / Profitability

Risk


Delivery

Swift




Workflow

Types of advices

Delivery

advices

Deal confirmation slip

Printed and handed over

across the counter

1. Customer record opening

2. Issuing Drafts

3. Teller transactions

Delivery advices to Customers,

Other banks about various events

Can be outward or inward through

Swift or Print or Telex

1. Remitting funds

2. Reimbursement instructions

3. Rate change advice

Statement

of AccountsDeal slips

Statements

Sent to

Account

holders

periodically

For accounts, Statement of accounts are sent periodically by Print or

Swift

For other applications, it is possible to advice the client of a transactionthrough Deal slip and/or Delivery advice.

Deal slips are printed and issued across the counter





CORE – Delivery


CORE

Support Modules


MIS / Profitability

Risk


Delivery

Swift




Workflow

Delivery advices

Normal

Delivery

Soft

Delivery

Rules for production of messages on

authorisation of transaction are

hard coded.

Limited scope to change the contents

of the produced message.

Rules for production of messages user

definable.

Content of message is user definable.

Preview of message possible during Input.

Ability to override the defined rules at

transaction level

Available for specified modules (Trade Finance,

Guarantees etc)





CORE – Static tables related to CUSTOMER


CORE

Support Modules

Accounting

General Ledger

MIS / Profitability

Risk


Delivery

Swift




Workflow

CUSTOMER

COUNTRY

RELATIONSHIP

MANAGER

LANGUAGE

SECTORTARGET

INDUSTRY

CUSTOMER STATUS

RELATION

The above diagram illustrates the various static tables that are linked to

the CUSTOMER file.

These are maintained through Administrator menu

Later on in CUSTOMER session we will make use of these tables.

COUNTRY table contains the static details of each individual Country,

for example, Country Name, Currency Code(s) etc. This is used to

indicate residence and nationality of a Customer

DEPT.ACCT.OFFICER : Identifies the main Account Officer responsible

for the Customer. It is useful for relationship management and also for

MIS purposes

SECTOR table helps grouping of customers at a top level for severalpurposes. The sector is commonly used to define the ‘Legal Status’ of

the customer i.e.., Individual, Public Company, Government,

Corporation, Trust etc.

INDUSTRY table defines the activity or business the customer is

involved in.

RELATION table is used to specify the various types of relation that

could exist between one Customer and another.

TARGET table helps group Customers for future marketing purposes





CORE – Static tables related to Holidays


CORE

Support Modules

Accounting

General Ledger

MIS / Profitability

Risk


Delivery

Swift




Workflow

HOLIDAY

COUNTRY

Static details of each country like Name,

Currency code, Consumer goods index etc

REGION

Helps define upto 99 Regions within a

Country where public holidays differ

from other parts of the Country.

Week ends, non week end holidays for

each region of every country year and

month wise defined here. All T24

applications check this during Input

Validation for events falling on holidays

These are maintained through Administrator menu. When we input transactions, we

will see how the System makes use of these tables.

COUNTRY: Contains static details of each Country, for example, Country Name,Currency Code 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: This 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 Application will refer to this table during input validation to check that if any

dates entered by the User are holidays and/or to raise an override to accept any

contract event that fall on a Holiday. It is also used to determine the delivery date, by

taking non-working days into consideration.





CORE – Static tables related to Currency


CORE

Support Modules

Accounting

General Ledger

MIS / Profitability

Risk


Delivery

Swift




Workflow

COUNTRY

CURRENCY PARAM

CURRENCY CURRENCY MARKET

FORWARD RATES

PERIODIC INTEREST

• Numeric Ccy Code

• Decimal Places for

rounding all calculations

• Interest Day Basis

• Precious Metal

• Equivalent Currencies

• Country Code

• Base Ccy Rank

• Upto 99 markets to

quote different rates

• Consolidated into 9

markets

For each Currency & Market, forward exchange

rates as premium / discount to the Spot rate for different Rest periods. To get the Rest date,

value in Rest period is added to SPOT date.

Used for Tolerance check and Rebate revaluation

• Bid and Offer rates for

different periods

• Interest tolerance for MM

• Used for automatic roll over

These are maintained through Administrator menu

When we input transactions, we will see how the System makes use of these tables

CURRENCY.PARAM: Contains common details for each Currency to ensure that thesame 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. 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. In the field EQUIVALENT.CCYS relationship must

be established to enable currencies to be used as interest or charge currencies on any

accounts set-up for the main currency. If two currencies are involved in a conversion,

then the currency with the lowest rank will take preference as base currency

CURRENCY.MARKET: Possible to create different market rates for the same

currency - Separate rates for Notes / Travelers Cheques etc. Consolidation keys are

formed market wise. Markets beyond 9 will be consolidated with the market type of thefirst digit – example 10 with 1.

FORWARD.RATES: The Rest periods can be defined either in months, e.g. 1 month,

or in days, e.g. 7 days, 15 days etc. To calculate the date of the rest period, the

system will add to the SPOT date the value defined in the field 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, however, this next working day

falls in the next month, the system will instead move BACKWARD to the previous

working day in the same month.





CORE – Interest related – INTEREST BASIS


CORE

Support Modules

Accounting

General Ledger

MIS / Profitability

Risk


Delivery

Swift




Workflow

Different Interest day basis for calculation of

interest possible depending on the method

followed for calculating number of days

in interest period and days in a year

For example, if Interest Basis B (366/360)

is selected, then the interest calculation

would look as follows:-

Principal Amt x Rate x 366 / 360

A1 Additional interest earned in February

calculated on last dayA2 Additional interest earned in February

calculated on penultimate day

In the options specified above the number on the left (Days)

(Numerator) represents the number of days basis for multiplying on the

top line of the interest calculation. Whilst number on the right(Denominator) is the basis for dividing on the bottom line of the interest

calculation and represents the number of days in the year.





CORE – Floating interest – BASIC INTEREST


CORE

Support Modules

Accounting

General Ledger

MIS / Profitability

Risk


Delivery

Swift




Workflow

BASIC RATE TEXT

BASIC INTEREST

Possible to set a negative interest rate for MM

Possible to give positive or negative spreads

Currency and

Interest effective date

part of ID

BASIC.INTEREST: This table allows various frequently used floating

Rates, e.g. Base Rate, Prime Rate, Overnight Rate etc., to be defined

separately for each Currency and stored in a central place where theycan be accessed, as required, by various Temenos T24 Applications.

'Prime records' with the same Interest conditions can be linked directly

to a Basic Interest ID in this table, rather than defining the Interest Rate

details on each transaction or contract record. For example, if the

overdraft interest conditions for Currency Accounts are related to the

base rate, each current Account or group of Accounts (when conditions

are applicable at group level), should refer directly to the Basic Interest

Rate ID defined in this table and not contain the value of the rate in

itself.When a rate change takes place, the user will then need to update only

the Basic Interest Rate IDs defined in this table with the new rate(s) and

the date on which it is to become effective. This will then automatically

update all the transaction/contract records which are tied to each

Interest ID.

A description of each rate is held in the BASIC.RATE.TEXT table to

allow the user to easily identify each one of the Basic Interest Rate

table ID's.





CORE – Floating interest – PERIODIC INTEREST


CORE

Support Modules

Accounting

General Ledger

MIS / Profitability

Risk


Delivery

Swift




Workflow

PERIODIC INTEREST

Bid rate is for Deposits

Offer rate is for Loans

Generated daily.

Back dated changes are also possible

Used for automatic roll over, Interest

Tolerance checking for MM

This table is used for “LIBOR” type rates of this nature . Rates vary

depending on the length of time and for Bid and Offer purposes.

For Loans and Deposit contracts that are linked toPERIODIC.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 MM contracts.





CORE – General Charges for Accounts


CORE

Support Modules

Accounting

General Ledger

MIS / Profitability

Risk


Delivery

Swift




Workflow

GENERAL CHARGEGENERAL CHARGE

BALANCE

REQUIREMENT

BALANCE

REQUIREMENT

ADDITIONAL

DEBIT INTEREST

ADDITIONAL

DEBIT INTEREST

GOVERNMENT

MARGIN

GOVERNMENT

MARGIN

NUMBER

OF CREDIT

NUMBER

OF CREDIT

TURNOVER

CREDIT

TURNOVER

CREDITINTEREST

STATEMENT

INTEREST

STATEMENT

TRANSACTION

CHARGE

TRANSACTION

CHARGE

HIGHEST

DEBIT

HIGHEST

DEBITNUMBER

OF DEBIT

NUMBER

OF DEBITTURNOVER

DEBIT

TURNOVER

DEBIT

ACCOUNT

STATEMENT

CHARGE

ACCOUNT

STATEMENT

CHARGE

The charges applied to an account will vary from Bank to Bank and

from different categories of account.

For example:

1) charges may relate to volume of turnover and defined in the files

NUMBER.OF.DEBIT and NUMBER.OF.CREDIT or

2) charges may be applied to the issue of statements and defined in the

file ACCT.STATEMENT.CHARGE

Several such charge tariff structures may be stored in the file

GENERAL.CHARGE .

A particular GENERAL.CHARGE record could be linked to a group of

accounts, say all current accounts, or all current accounts of UKresidents or even to an individual account





CORE – Charges and Commission for other applications


CORE

Support Modules

Accounting

General Ledger

MIS / Profitability

Risk


Delivery

Swift




Workflow

FT.COMMISSION.TYPE: Each Commission Type can be defined as a

flat amount or as one which varies according to the amount. In the latter

case different percentages can be defined for different Bands or Levelsof transfer amounts. Minimum and maximum Commissions can be

specified for each Band or Level together with overall minimum or

maximum commission charges. 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 USD 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.5 percent over 10,000.

If Band is specified for all sub value groups, 2 calculations will beperformed, 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, ie. 1.5% on

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





CORE – Correspondents and Relationships


CORE

Support Modules

Accounting

General Ledger

MIS / Profitability

Risk


Delivery

Swift




Workflow

AGENCY records are established to

record Standard Settlement Instructions

for Correspondent Banks or

Customers for currency wise settlement.

• Credit Suisse wants all USD paid

to Merrill Lynch, New York.

• David Brown PLC wants all EUR

paid to Deutsche Bank, Frankfurt.

Obviates need to re-enter detailsat transaction level





Preferential grouping

• Possible to group customers/accounts for setting up of

interest/charge conditions

• Examples

– Interest rate of 1.75% p.a. is applicable on all Savings Accounts

however Staff Savings Accounts carry interest of 2% p.a.

– Commission for Draft Issue is 1.5% of the transaction value

subject to a minimum of £ 5. For high net-worth clients, the

percentage is reduced to 1%.

– Basic Rate Tax of 20% applicable for credit interest on

accounts/deposits held by Individuals, Sole-Proprietors &

Partnerships (not applicable for Corporates).


CORE

Support Modules

Accounting

General Ledger

MIS / Profitability

Risk


Delivery

Swift




Workflow





Temenos T24 Customisation scope

Temenos T24Implementation

Tape Enquiries & Reports

CustomisedTemenos T24

Parameters &Conditions

Screen Design

(Version)

User defined Routines

Local Reference Fields

Default field data

Every bank has its own unique needs/requirements from the software.

While Temenos has built `Model banks’, banks would still like to

configure the system to have their own choices of conditions, and holdadditional information, 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.





Temenos T24 Pre configured Model Bank

Temenos T24Implementation

TapeOver 50 Enquiries &

50 Reports

Pre configuredModel Bank

With business process

for all Banking operations

Standard Parameters& Conditions

Over 550

Versions

Over 100 Delivery set up

Essential LocalReference Fields

Default field data

Model Bank is generic T24 and does not contain local development

It uses Core T24 fundamentality to run bank business

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





Model Bank - Contents



Channel ServicesDesktop Browser



CORESupport Modules

Accounting

General Ledger

MIS / Profitability

Risk


Delivery

Swift


Corporate

Trade Finance

Guarantees

Commercial Loans

Syndicated Loans

General

Nostro Recs

Funds Transfer

Past Due

Tax

Image

Document mgt

Confo matching



Workflow

Treasury

FX

Money Market

Securities

(Own book)

Retail

AccountsCheques,

Statements, charges,sweeps, Direct debits

Mortgages / loans

Teller

Fixed deposits




Temenos T24 Functionality

Temenos T24 Core

Validation

UNAUTHORIZED

APPLICATION LOGIC

Static Data

Product Interest Rates Commissions Currency etc...

Risk Management

Credit Risk Market Risk

Collateral

AUTHORIZED

MIS / Profitability

Accounting

General Ledger Debits/Credits

Regulatory Reporting

SWIFT SID Interface

Messages/Clearing

Print

Custom Interfaces

RDBMS

Authorizer

Close of Business

Accruals Maturity Control Reporting Revaluation

Queries


Transaction Input

or

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 being

used). Then the respective delivery messages are generated, 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.

Overview on Temenos T24

Documents

Transcript of Overview on Temenos T24