T24 Overview - R11.1

T1TOL – Overview - R10.1

1

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


2

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


2

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


3

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


4

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


5

In a Bank, everything revolves around its customers. Similarly, all business applications make use of the static information of a customer. Product centric software store information based on their products and hence have to maintain various details banking product wise, like address for communication, just to name one. T24 works on centralised Customer details. All descriptive details of a Customer are stored only in CUSTOMER application. Every business product takes the requisite Customer information from here. Thus, if we need information on loans given industry wise, it is not necessary to have industry wise classification at loan level. It is possible to pick out the Customer from a loan, find out his industry from his record in CUSTOMER application and accordingly consolidate loans for a given industry. The advantage under this system of holding information is easy maintainability of information. If the Customer‟s industry changes, then it is adequate if this change is made once in the Customer record. If the Customer has five accounts and three loans, all of them would get automatically regrouped 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,


6

besides department wise.


6

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


7

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


7

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


8

All these groups are differentiated by using suitable CATEGORY code.


8

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


9

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


10

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


10

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


11

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


12

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


13

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


14

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


15

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


16

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


17

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


18

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


19

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


19

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


20

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


21

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


22

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


23

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


24

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


24

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


25

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


26

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


27

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


28

AA module provides a flexible framework to create products in T24. It provides a component based architecture for building and managing business products. Products are assembled from combinations of reusable components. For example, a Housing loan product may be designed from components like Customer, Account, Principal Amount, Interest rate, Charges, Principal and Interest repayment conditions etc. It is quite possible that a Bank may have say ten interest rate definitions which are used across different types of loans, deposits and accounts. Hence, if these ten components are created, then they could be used across any desired product of the Bank.

It is also likely that a Bank may like to set a rule that when it changes definition of a fixed interest rate, then that should be made applicable only for new loans and not for existing loans. Then the changes to loan definition are not tracked for existing arrangements. AA Lending is designed to handle complex requirements of retail business. It is possible to set which condition should be allowed to be negotiated by users, and if need be within what boundaries. For example, it could be set that only the margin on a floating rate could be negotiated and not the underlying rate, and it could be negotiated only between 1 and 1.25.

As AA offers account based lending facility, payment and receipts can be


29

processed directly from any interfaced channel.


29

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


30

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


31

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


32

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


33

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

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

34

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


34

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


35

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

Disclosure value is held as an off balance sheet value in the CRB


36

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


37

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


38

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


39

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


40

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


41

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


42

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


43

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


44

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


45


46

T24 Overview - R11.1

Recommend Documents