Overview on Temenos T24

Overview of Temenos T24 Model Bank • 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 Copyright © 2004 TEMENOS HOLDINGS NV criminal penalties, and will be prosecuted to the maximum extent possible under applicable law.” Information in this document is subject to change without notice.

Copyright © 2006 TEMENOS HOLDINGS NV

T24 Model Bank Introduction (T2MBIN-R5) - Overview

1

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 the world 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.


2

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


3

Temenos T24 Functional Architecture Web

Call Centre

Channel Services

Mobile

Version

Browser

Presentation

Web Svcs

IVR

Enquiry

Security Management System Static

Overview

Customer

Trust /Private

Treasury

Contact History

Retail Accounts

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

Mortgages / loans Teller Mutual Funds*

Wealth Management

Profitability

Preferences and Groups

Corporate

General

FX

Performance Modeling…

Trade Finance

Nostro Recs

Money Market

Commercial Loans

Confo matching

Fiduciaries

Swaps

Guarantees

Fixed deposits Brokerage

FRA

Cash Management

Repos

Syndicated Loans

Capital Markets

Leasing

Image

Futures/Options

Bills

Document mgt

Asset Management

Order processing Corporate Actions…

Planning

Accounting

MC/ MB

Dev Toolkit

General Ledger MIS / Profitability

Multi Currency Language,

Programming Database

CORE Support Modules

Workflow Exception STP Dispo

Funds Transfer Euro Past Due Intermediary comp Tax

Risk Limits / Collateral Market Risk

Delivery Swift / FIX Print / Telex / Other

Security Management System Copyright © 2005 TEMENOS HOLDINGS NV

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.


4

Temenos T24 Technical Architecture Web

Call Centre

Channel Services

Mobile

Version

Browser

Presentation

Web Svcs

IVR

Enquiry


Overview

Customer

Trust /Private

Treasury

Contact History

Retail Accounts

Wealth Management

Profitability


Corporate

General

FX

Performance Modeling…

Trade Finance

Nostro Recs

Money Market

Commercial Loans

Confo matching

Fiduciaries

Swaps

Guarantees

Fixed deposits Brokerage

FRA

Cash Management

Repos

Syndicated Loans

Capital Markets

Leasing

Image

Futures/Options

Bills

Document mgt

Asset Management

T24 Server

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

Mortgages / loans Teller

Order processing Corporate Actions…

Mutual Funds*

Planning

Accounting

MC/MB

Dev Toolkit

General Ledger MIS / Profitability

Multi Currency Language,

Programming Database


Workflow Exception STP Dispo

Funds Transfer Euro Past Due Intermediary comp


Tax

Delivery Swift / FIX Print / Telex / Other

Security Management System Copyright © 2005 TEMENOS HOLDINGS NV

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


5

P r e s e n t a t io n

S c a le

Temenos T24 Technical Architecture - Resilience Multi-channel

MQ APIs Excel etc. Browser

GIB Internet

Web Services

Enterprise Console

API – Java and COM

Other connectivity

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

Web Server

T24 Browser component

M

L

C o n n e c t iv it y

S c a le

Network Dispatcher

NO SINGLE POINT OF FAILURE

A p p lic a t io n

Presentation

Presentation

Presentation

Linux, IBM I/Z Series, HP, Unix, Windows C object code

NON-STOP

D a t a b a s e

S c a le

S c a le

X

Load Balancer

No batch Non Stop! Oracle, DB2, J4 Cluster Installation


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.data directory), 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


6

CORE - CUSTOMER

Static

Contact History

Overview

Customer

Profitability


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…

Accounting General Ledger MIS / Profitability

MC/MB Multi Currency Workflow



Delivery Swift Print / Telex / Other


7

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.


7

CORE – Accounting Static

Contact History

CATEGORY

Accounts 01000 - 19999

Contracts 20000 - 49999

Profit & Loss 50000 - 69999 Accounting General Ledger MIS / Profitability

Overview

Customer

Profitability

Customer Accounts Current accounts Vostro accounts Nostro accounts Saving accounts


01000 - 9999 1000 - 1999 2000 - 2999 5000 - 5999 6000 - 6999

Possible to accrue interest

Internal Accounts Cash accounts Fixed Assets, Suspense etc

10000 – 19999 10000 – 10999 11000 – 19999

Not possible to accrue interest

LD and MM Sub-blocks range

21000 – 21999 21001 – 21029 21050 – 21074 21075 – 21084

Deposits Takings Loans Placements

Product related PL

50000 – 59999 50000 – 50999 51000 – 51999 52000 – 52999

Interest paid Interest received Commission

Non Product related PL



60000 and above 60000 – 60999 62000 – 62999


Salaries Operating expenses



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 an Account permits the 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 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 T24 Model Bank Introduction (T2MBIN-R5) - Overview

8

CORE – Accounting entries Static

Contact History

Overview

Customer

Profitability


STMT.ENTRY

Entries affecting Account balances

RE.CONSOL. SPEC.ENTRY

Entries affecting all other Assets & Liabilities

CATEG.ENTRY

Entries affecting PL Heads

ASSETS & LIABILITIES

PROFIT & LOSS Accounting General Ledger MIS / Profitability






9

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. Accounting entries 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


9

CORE – General Ledger and other reports Static

Contact History

Entries affecting Account balances

Entries affecting all other Assets & Liabilities

Entries affecting PL Heads


Overview

Customer

Profitability


STMT.ENTRY

ASSETS & LIABILITIES Key Consolidation based On Customer and Application information REPORT CREATION HEADER LINE COLUMN …………... …………..…

RE.CONSOL. SPEC.ENTRY

CATEG.ENTRY



PROFIT & LOSS Key Consolidation based On Customer and Application information Risk Limits / Collateral Market Risk



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 reports, respectively lines. Before creating lines, we need to create the columns and the header.


10

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

Contact History

Overview

Customer

Profitability


• 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 and reported)







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 and 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. 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 using COMPANY.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


11


Contact History

Overview

Customer

Profitability


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







12

Customer accounts and contracts can be transferred from one Company to the other, without actual closure. Their Ids will continue to be same Possible 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: USD12800-0011-0001 Accounting entries automatically passed at Branch 3 DR. Inter-Branch Account : HO USD-12800-0001-0011. CR. Current Account of Customer


12


Contact History

Overview

Customer

Profitability


• 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








13

13

CORE – Limits Static

Contact History

Overview

Customer

Profitability


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


Multi Book Multi Currency Workflow





14

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; 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 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. T24 Model Bank Introduction (T2MBIN-R5) - Overview

14

CORE – Delivery Static

Contact History

Overview

Customer

Profitability


•

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 systemwide and up to the Customer or account level. Accounting General Ledger MIS / Profitability







15

15


Contact History

Overview

Customer

Profitability


• 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

16


Contact History

Overview

Customer

Profitability


Types of advices Statement of Accounts Statements Sent to Account holders periodically


Deal confirmation slip Printed and handed over across the counter 1. Customer record opening 2. Issuing Drafts 3. Teller transactions


Delivery advices

Deal slips


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




17

For accounts, Statement of accounts are sent periodically by Print or Swift 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


17


Contact History

Customer

Overview

Profitability


Delivery advices Soft Delivery

Normal Delivery Rules for production of messages on authorisation of transaction are hard coded.

Rules for production of messages user definable. Content of message is user definable. Preview of message possible during Input.

Limited scope to change the contents of the produced message.

Ability to override the defined rules at transaction level Available for specified modules (Trade Finance, Guarantees etc)








18

18

CORE – Static tables related to CUSTOMER Static

Contact History

Overview

Customer

RELATION

CUSTOMER STATUS

Profitability


COUNTRY

CUSTOMER

RELATIONSHIP MANAGER

LANGUAGE INDUSTRY TARGET Accounting General Ledger MIS / Profitability



SECTOR




19

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 several purposes. 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 T24 Model Bank Introduction (T2MBIN-R5) - Overview

19

CORE – Static tables related to Holidays Static

Contact History

Overview

Customer

Profitability


Static details of each country like Name, Currency code, Consumer goods index etc

COUNTRY REGION

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

HOLIDAY

Validation for events falling on holidays

Helps define upto 99 Regions within a Country where public holidays differ from other parts of the Country. Accounting General Ledger MIS / Profitability






20

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.


20

CORE – Static tables related to Currency Static

Contact History

Overview

Customer

Profitability


COUNTRY

• Numeric Ccy Code

• Upto 99 markets to

• Decimal Places for

quote different rates

rounding all calculations

CURRENCY PARAM

• Interest Day Basis • Precious Metal

• Consolidated into 9 markets

• Equivalent Currencies

CURRENCY

• Country Code

CURRENCY MARKET

• Base Ccy Rank

FORWARD RATES For each Currency & Market, forward exchange rates as premium / discount to the Spot rate for different Rest periods. To get the Rest date,

• Bid and Offer rates for different periods • Interest tolerance for MM • Used for automatic roll over

value in Rest period is added to SPOT date. Used for Tolerance check and Rebate revaluation Accounting General Ledger MIS / Profitability



PERIODIC INTEREST Risk Limits / Collateral Market Risk



21

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 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. 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 the first 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.


21

CORE – Interest related – INTEREST BASIS Static

Contact History

Overview

Customer

Profitability


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 day A2 Additional interest earned in February calculated on penultimate day Accounting General Ledger MIS / Profitability






22

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.


22

CORE – Floating interest – BASIC INTEREST Static

Contact History

Overview

Customer

Profitability


BASIC RATE TEXT Currency and Interest effective date part of ID

BASIC INTEREST

Possible to set a negative interest rate for MM Possible to give positive or negative spreads Accounting General Ledger MIS / Profitability






23

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 they can 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.


23

CORE – Floating interest – PERIODIC INTEREST Static

Contact History

Overview

Customer

Profitability


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







24

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 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 MM contracts.


24

CORE – General Charges for Accounts Static

Contact History

Overview

Customer

Profitability

TURNOVER TURNOVER

NUMBER NUMBER OF OF CREDIT CREDIT

BALANCE BALANCE REQUIREMENT REQUIREMENT

ACCOUNT ACCOUNT STATEMENT STATEMENT CHARGE CHARGE


CREDIT CREDIT

GENERAL GENERAL CHARGE CHARGE

INTEREST INTEREST STATEMENT STATEMENT

TRANSACTION TRANSACTION CHARGE CHARGE

ADDITIONAL ADDITIONAL DEBIT DEBIT INTEREST INTEREST

GOVERNMENT GOVERNMENT MARGIN MARGIN Accounting General Ledger MIS / Profitability


NUMBER NUMBER OF OF DEBIT DEBIT

TURNOVER TURNOVER DEBIT DEBIT



HIGHEST HIGHEST DEBIT DEBIT Delivery Swift Print / Telex / Other


25

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 UK residents or even to an individual account


25

CORE – Charges and Commission for other applications Static

Contact History


Overview


Customer

Profitability






26

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 Levels of 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 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, ie. 1.5% on 100,000. If Flat is specified, the basic Flat Amount will be applied.


26

CORE – Correspondents and Relationships Static

Contact History

Overview

Customer

Profitability


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 details at transaction level Accounting General Ledger MIS / Profitability







27

27

Preferential grouping Static

Contact History

Overview

Customer

Profitability


• 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).








28

28

Temenos T24 Customisation scope Parameters & Conditions

Local Reference Fields

Temenos T24 Screen Design (Version)

Implementation Tape

Enquiries & Reports

Default field data

User defined Routines

Customised Temenos T24 Copyright © 2005 TEMENOS HOLDINGS NV

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 hold additional 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.


29

Temenos T24 Pre configured Model Bank Standard Parameters & Conditions

Essential Local Reference Fields

Temenos T24 Implementation Tape

Over 550 Versions

Over 50 Enquiries & 50 Reports

Default field data

Over 100 Delivery set up

Pre configured Model Bank With business process for all Banking operations Copyright © 2005 TEMENOS HOLDINGS NV

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


30

Model Bank - Contents

Channel Services

Desktop

Version

Browser

Presentation

Enquiry


Contact History

Retail

Treasury

Mortgages / loans Teller

Profitability


Corporate

General

FX

Trade Finance

Nostro Recs

Money Market

Commercial Loans

Confo matching

Securities

Guarantees

Funds Transfer

(Own book)

Syndicated Loans

Past Due

Accounts

Cheques, Statements, charges, sweeps, Direct debits

Customer

Overview

Tax Image

Fixed deposits

Document mgt Accounting General Ledger MIS / Profitability





Security Management System



31

31

Temenos T24 Functionality or

Transaction Input

Authorizer

Queries Security Management System RDBMS

APPLICATION LOGIC

Temenos T24 Core Close of Business

Validation AUTHORIZED

UNAUTHORIZED Static Data Product Interest Rates Commissions Currency etc...

Risk Management

Messages/Clearing

Credit Risk Market Risk Collateral

Print SWIFT SID Interface Custom Interfaces

Accruals Maturity Control Reporting Revaluation

Accounting General Ledger Debits/Credits MIS / Profitability Regulatory Reporting


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.


32

Overview on Temenos T24

Recommend Documents