T24 CORE BANKING SYSTEM
CONTENT
I. FUNCTIONAL A RCHITECTURE ....................................................2
II. CORE SUPPORT MODULES ........................................................3
A. CUSTOMER INFORMATION FILE .............................................3
B. ACCOUNTING/GENERAL LEDGE .............................................3
C. MIS/PROFITABILITY ..................................................................5
D. WORKFLOW ...............................................................................5
E. LIMIT ...........................................................................................6
F. COLLATERAL .............................................................................6
G. DELIVERY ..................................................................................7
H. SECURITY MANAGEMENT SYSTEM........................................7
I. COMMON LISTS ..........................................................................8
J. RISK MANAGEMENT (CREDIT SCORING)................................8
K. MULTI COMPANY................... ....................................................9
III. BUSINESS MODULES ..................................................................9
A. CORPORATE BANKING.............................................................9
B. RETAIL BANKING .....................................................................13
C. TREASURY........................ .......................................................16
D. PRIVATE BANKING ..................................................................19
E. GENERAL .................................................................................21
IV. SPECIAL IZED CONNECTION GATEWAYS .............................. 25
A. IBPS ..........................................................................................25
B. BankNet.....................................................................................25
C. SBV REPORT ...........................................................................25
D. SWIFT .......................................................................................25
E. Reuters 3000 Xtra .....................................................................25
F. International Card Organizations ...............................................25
G. Internet banking ........................................................................26
H. Mobile banking ..........................................................................26
V. T24 SYSTEM ARCHITECTURE MODEL ....................................27
VI. SYSTEM ARCHITECTURE CONTENTS.......................... ..........28
A. SYSTEM COMPONENTS .........................................................28
B. MIDDLEWARE AND INTERFACES ..........................................30
C. SECURITY ................................................................................30
D. MONITORING ...........................................................................31
I. FUNCTIONAL ARCHITECTURE
Web Call
Centre Mobile Channel Services Browser W eb
Svcs IVR
Version Presentation Enquiry
Security Mana gement System
Sta tic Contact History Overvie w Customer Profitability Pre fere nces and Groups
Retail Trust /Private Treasury Corporate General
Wealth Management
Ass et Management FX Trade Finance Nostro Recs
Accounts Performance
DDA, checks, cards, Modeling… Money Market Commercial Loans Confo matc hing
statements, charges, Funds Transfer
sweeps, direct debits Fiduciaries Swaps Guarantees
Euro
Mortgages / loans Fixed deposits FRA Cash Management Past Due
Brokerage Intermediary comp
Teller Order processin g Repos Syndicated Loans
Corporate Actions… Tax
Mutual Funds *
Capital Markets Leasing Image
Planning
Futures/Options Bills Document mgt
Accounti ng Multi Dev Toolkit Workflow Risk Delivery
CORE Exception STP Limits / Collateral Swift / FIX
General Ledger Company, ccy Programming
Support Modules Dispo Market Risk Print / Telex / Other
MIS / Profitabi lty Language , G AC Database
Security Management System
II. CORE SUPPORT MODULES
Modules Description
A. CUSTOMER A Customer is an entity either individual or non-individual who
has been accepted by your institution to conduct business with
INFORMATION FILE
and as such a Customer record will need to be opened on
Model Bank (T24) to reflect this.
As T24 is a customer-orientated system all accounts, except
internal accounts, will be connected to a CUSTOMER record.
The customer application contains all the basic information
about any client with which the bank has dealings.
Consequently, a CUSTOMER record will need to be opened for
correspondent banks, brokers, guarantors etc as well as the
more ‘traditional customers’ who maintain current, saving and
loan accounts with your institution. Most applications within T24
will refer to the CUSTOMER record during processing and as
such they should be opened before any customer activity is
recorded in T24. The existence of these CUSTOMER records
will minimize the required input of data on certain transactions
e.g. MM.MONEY.MARKET, FOREX etc where details of banks
(who are ‘customers’ of your institution) are nearly always
necessary to indicate the settlement details of these
transactions.
One of the great advantages of being a customer-orientated
system is that the static data of the client only needs to be input
once regardless of the number of accounts, in any currency
that they may require. This also eliminates the need for
extensive maintenance of customer information when for
example a customer changes their address. It should be
remembered that the details on the actual CUSTOMER record
are only descriptive and not financial, the balances where
appropriate will be stored under the ACCOUNT application.
A customer can be a:
• Individual customer
• Corporate customer
B. ACCOUNTING/GENE All transactions / contracts create the relevant accounting
entries across the clients accounts and for the banks own
RAL LEDGE internal records
Entries are automatically generated for authorised transactions
Combination of entries generated from STMT.ENTRY,
CATEG.ENTRY and RE.CONSOL.SPEC.ENTRY
There is no need for a consolidated General Ledger account
for accounting entries – only `virtual’ accounts. Hence
information is held at a KEY (grouping condition) level
T24 CORE BANKING SYSTEM
ACCOUNTS: Positive and Negative signs (+ / -) for balances
interchangeable
• Customer type Accounts: Current Account, Savings
Account, Nostro Account, Vostro Account etc
• Internal Accounts (Assets & Liabilities in nature):Cash
Account, Suspense Account, Furniture Account etc
CONTRACTS: Balances can have only one sign as determined
at the beginning and generally has a stated beginning and end.
Types of contract are as follow:
• Loans
• Deposits
• Money Market
• Securities
• Foreign Exchange
PROFIT & LOSS HEADS
• Interest earned account, Salary account, Miscellaneous
expenses account etc
• (In T24, we do not open accounts for P & L heads, but
balances consolidated through use of Category codes and
consolidation keys)
T- 24 APPLICATIONS
• Account based applications are used to move money
between accounts – Customer type, Internal or P & L type.
They cannot be used to generate contracts / deals.
• Contract applications are used to generate contracts and
resultant movements in accounts
CATEGORY CODES
• In T24, Category codes reflect accounting plan and used to
classify transactions by products such as Customer
Accounts, Internal Accounts, Contracts and Profit and loss
items and sub-products
•
For financial operations,
automatically category
if parameterized codesbe
or could are assigned
input where not
parameterized
• Category codes, together with fixed choices of consolidation
and user selection criteria defined in
CONSOLIDATE.COND table, like Residence and Industry,
help banks produce reports reflecting a coordinated and
structured view of their operations
4/31
T24 CORE BANKING SYSTEM
C. MIS/PROFITABILITY The TEMENOS Model Bank (T24) Management Information
(MI) has been designed to provide financial management
information on customers, products, departments, income and
expense, average balances and other information, from which
management may analyze profitability and performance. The
system consists of a series of user definable databases,
constructed periodically from which reports and enquiries can
be generated. For the purposes of the Model Bank, 4 sample
databases have been set up and the procedure for building
them is explained. Example reports and enquiries are provided
to illustrate the potential uses of the system and to provide
prototypes upon which users may base their own system.
This module includes these below aspects:
• Building Balance Movement file
• View Balance Movement Records
• Build Customer Loan Product Profitability database
• Build Non Interest Income Analysis database
• Build Interest Income & Expenses Analysis database
• Build Operating Expense Analysis database
• Viewing Reports
D. WORKFLOW T24 Process Workflow (PW) is aimed at grouping the various
activities of the bank into a logical process. This grouping
further enables allocation of work to different users, tracing the
path of a particular process dynamic decision-making process
as regards to the sequence and number of activities. The
individual activities are defined at micro level and the rules,
status and the user groups are defined to be reused. This
module does not carry any business functionality but can be
used to define and tune the flow of business supported by
other T24 modules.
PW enables speedy creation of activities and also linkages to
the defined activities through Process workflows. By providing
tools in this arena we can significantly reduce the time it takes
to implement a system-oriented process and also well reduce
the level of expertise required. Process Workflow definitions
and activities are stored in T24 and they can be imported /
exported via XML into a variety of modeling tools for
manipulation, simulation and update back to T24. Standard
features on
queries of both
T24 enable ad hocofand
the evolution scheduled
a given reports
process and
workflow
definition and any given instance of a process.
Features of Process workflow:
• Tools given reduce the implementation time and reduce
requirements of expertise
• Activities can be defined micro level.
• Rules, status and the user groups can be reused
5/31
T24 CORE BANKING SYSTEM
• PW module is a rule based workflow engine.
• PW enables import/export of Process Workflow.
• Workload balancing across participants.
• New activities are created automatically and assigned to
participants according to the activity
• definition and participant definition.
• Enables tracing the path of a particular process.
• Passing dynamic values between activities or across the
process workflow.
• A tool to monitor Process productivity and Time utilization.
E. LIMIT The LIMIT system controls credit risk against customers and
markets. It monitors the availability and utilization of credit
limits in the following categories:
• Customers and groups of customers
• Countries and groups of countries
• Commodities
• Currencies
Customer limits are monitored in real-time during Model Bank
(T24) on-line transaction processing. Other limits are monitored
and reported on during the Model Bank (T24) overnight batch.
Limits may be established at two levels individual and group.
Individual limits are those where the concerned customers are
liable only for themselves. Group limits can be set up for
Corporate Clients under the same control and individuals of the
same family Examples of these will be given later in the
document.
Limits can be either non-revolving (reducing) or revolving
(revolving). Non-revolving will reduce with each repayment e.g.
Term Loan whereas Non-reducing will not be affected by
repayment e.g. Overdraft.
By way of a brief summary, within Model Bank (T24) Credit
Limits are held on the LIMIT application. Sub-products,
products, and global definitions are held on the
LIMIT.REFERENCE application. Customers and customer
liability definitions are held on the CUSTOMER application.
Finally the LIMIT.PARAMETER application defines various
high level parameters concerning the application and also links
contracts and accounts to LIMIT.REFERENCE. These files will
be explained in greater detail later in the document.
The LIMIT system also integrates closely with the
COLLATERAL application.
F. COLLATERAL COLLATERAL can be linked into the LIMIT module, and allows
the definition and control of collateralized limits. Unlike LIMIT
which is a core module which will be invoked by CORE
6/31
T24 CORE BANKING SYSTEM
immaterial of the Bank’s practices, COLLATERAL is optional
and needs to be implemented only if the Bank has the
requirement.
An item of collateral can take many forms and could vary from
a ship to a house or from paintings and sculptures to a single
stamp or an entire collection. These items can then be valued
against the market value on a set frequency or ad-hoc basis.
Items which are contained within Model Bank (T24) itself may
be valued automatically, especially in cases such as a Deposit
Account,
of stocks fixed term While
& shares. Deposit, or all
there will(or
bepart) of like
others a Client
fixedportfolio
assets,
paintings etc for which the value needs to be filled in manually
for the system to take into reckoning
G. DELIVERY • The Delivery module integrates with the business
applications and transactions, and will generate appropriate
messages.
• A background process - it requires Activities, Advice codes
and format of messages to be defined for each application.
• The messages are generated when a transaction is
authorized, details of these will be recorded on transaction
& can be viewed using enquiries
• The Delivery Reference or Message Identifier can be found
in the srcinating transaction record when authorized
• It is the unique ref no to track the message through the
Delivery process
The Delivery System manages the flow of all messages from
T24, such as confirmations, payments and advices whilst
giving users full control over formatting and language of
presentation. Messages are generated automatically as soon
as contract entry is complete or when a scheduled diary event
occurs. All messages may be either printed or sent via
electronic carrier systems, such as SWIFT, Telex, etc.
Messages from external carrier systems are received by the
Delivery System and, if necessary, formatted according to the
user-determined requirements. Following this, printed output
containing the incoming information is produced. For example
Payment messages are passed onto the FUNDS.TRANSFER
module, which, after authorisation, updates accounts and
related information.
Although the Delivery process is fully automated, users may
take control over many aspects of message management. For
this purpose, facilities are provided to inspect and control
message queues; graphical displays are available giving a view
of queue status, such as the volume of traffic by priority and
carrier. Once queued, individual messages may be displayed,
amended or re-routed.
H. SECURITY The Security Management System (SMS.) controls who is
7/31
V. T24 SYSTEM ARCHITECTURE MODEL
VI. SYSTEM ARCHITECTURE CONTENTS
A. SYSTEM COMPONENTS
A.1. A pp lic ati on ser ver
The T24 Application server is the core component of the TEMENOS T24 solution. It
includes the business logic of the T24 solution.
A.1.1. Operating system
T24 can support following operation systems:
- Windows
- NT
- UNIX
- LINUX
- …
Currently, The Operating System chosen by MILITARY Bank and SEABank to
support their Core Banking solution is IBM AIX. The TEMENOS T24 solution is
generally available for the AIX operating system.
A.1.2. Application framework
The T24 application will be delivered on jBase Application Framework release 4.1.
The generally available release of jBase 4.1 products for the defined Operating
System will be used.
A.2. Dat abase ser ver
T24 can support following database:
- Oracle
- DB2
- jBase
A.2.1. jBase 4.1 Database engine
The T24 Database will be implemented on jBase 4.1 engine. This database engine
enables connectivity to databases and data files through the jBase External Device
Interface.
A.2.2. Oracle 10g Database engine
The T24 Database can also be implemented on Oracle 10g engine. The connectivity
from T24 Application to the database will be done using Oracle OCI. This will enable
Oracle standard implementation in terms of architecture, like cluster and replication.
The link to Oracle database at the T24 application server level will be done with the
jBase External Device Interface for Oracle XML: jEDI Oracle XML.
A.3. B ro ws er s erv er
The T24 Browser server is the T24 Web Application Server. It provides Microsoft
Internet Explorer 5.5 (and above), which will have access to the different versions
and enquiries provided by T24
The T24 Browser server runs on the top of a web and servlet server. At this stage,
T24 CORE BANKING SYSTEM
T24 Browser server is generally available for the Tomcat Apache web and servlet
server release 4.1.12.
The release number of Apache Tomcat to be used for the T24 Browser provided will
be confirmed at build time.
A.4. T24 Deskt op
The T24 Desktop is Visual Basic thin client. It runs on Microsoft Windows
Workstations and Professional releases of NT 4.0 and above. It is recommended
that the Bank should implement the T24 desktop client initially. The Bank is required
to acquire the Web server in order to launch the T24 Browser. Once the Web server
is configured and launched, a plan for the smooth replacement of the Desktop by
T24 Browser can be achieved
The generally available release of the T24 Desktop, supporting Unicode UTF-8 and
SSL encryption with the T24 Application server, is 1.4
A.5. TEMENOS con nec to r
The Temenos Connector allows external programs to link to T24 via the OFS (Open
Financial Service) module. The java TCServer opens up T24 to external access via
OFS. This can be done using many different channels, including MQSeries, TCP,
SSL
The Temenos Connector consists of:
A.5.1. Server side tCS
The TEMENOS Connector Server, tCS, is providing T24 standard connectivity to the
sub-systems. It is generally available in release 1.3.
The TEMENOS Connector server does not support automatic character translation,
neither does OFS. The character translation will be provided either by the sub-
system server of the Bank environment, which will also ensure support for the
OFSML message parsing both ways; or by a translation routine at the tCS level.
Bank is can use MQ Series message bus to secure the message delivery in-between
solutions
A.5.2. Client side tCC
The TEMENOS Connector Client, tCC, is presently available in two different
releases: java and COM+.
The integration requirements of this project; with the Front-End environment
developments for Internet Banking, As the present teams are also working on the
Windows environment, the tCC COM+ will also be used
A.6. Temeno s c on nectio n m anager
The TEMENOS T24 Connection Manager provides connectivity from T24 Desktop to
T24 Application servers.
- JconMan :The TEMENOS Connection Manager is receiving the T24 Desktop
Connection requests and returns back the information of the T24 Application
server they can connect to
- jConServ : The TEMENOS Connection Service is providing T24 Connection
Manager with its availability information
29/31
T24 CORE BANKING SYSTEM
B. MIDDLEWARE AND INTERFACES
The technical solutions for interfacing with external system (IBPS, SWIFT, Reuters
3000, SBV report…) are as follow :
B.1. Direct in terfaces
The file base import and export features will be supported with ftp and dedicated
directories. The file base export requiring push will use scripts to perform this “file
push”.
There is no real time processing for file transfer, the files will be processed through
batch services, for both incoming and outgoing files
B.2. Indirect int erfaces
The Front End link to T24 Application server will be done through the TEMENOS
Connector Client API. The development to integrate TEMENOS Connector Client
API and Front End environment is not part of TEMENOS project scope.
- Message Bus: The IBM Message Queue, MQ Series, will be supported via the
tCC and tCS connection and via native MQ Series support from tCS
- TCP/IP sockets : The IP Socket messages will be supported via the tCC and
tCS connection and via native IP socket support from the tCS
C. SECURITY
C.1. Security management system (SMS)
The SMSthe
access, module of T24 is and
functionalities part the
of the Core of of
perimeter thethe
T24 product.
user It enables
business to limitinput
transaction the
and output.
It is a business module. The description of the scope and deliverables for the SMS
module are part of a separate document addressed through TEMENOS business
consultant specialists
C.2. Encryp tio n
TEMENOS T24 implements encryption to the standard communication mechanism:
- Desktop communication to T24 server, using IP socket, via jConMan and
jConServ.
- TEMENOS Connector Client API, using IP socket, via Connector server tCS.
- tCS direct communication from MQ Series or IP port, using TEMENOS
Connector encryption methods.
The implementation of encryption is not defined at this stage and a review of the
resulting increase in communication volumes is advised before going in this direction
C.3. Connecti on manage r
Connection server accepts the protocol SSL v2/v3 and TLSv1. For security reason,
the version 2 of SSL is disabled.
The connection manager solution doesn’t provide a PKI (Public Key Infrastructure).
You must implement a policy regarding the generation of certificates
C.4. TEMENOS conn ecto r
30/31
T24 CORE BANKING SYSTEM
The encryption provided by TEMENOS Connector is based on symmetric
cryptography. It supports SSL v3 protocol.
TEMENOS Connector provides methods to create and manipulate the Certificates
and process the encryption.
The TEMENOS Connector Client is providing direct support for encrypted
communications.
When using native IP communication sources to TEMENOS Connector Server,
some TEMENOS Connector methods will have to be used to provide both the
support for encryption and the formatting of the messages to be sent
D. MONITORING
D.1. Log information
The T24 database provides the PROTOCOL file, which is updated real-time by T24.
All logs information are stored in the PROTOCOL file as text messages.
It is possible to follow the business activity of the T24 Application servers by
monitoring the PROTOCOL file
D.2. Enterpr ise Conso le
The T24 Entreprise Consol provides Information Panel, Summary and Detail views
of the T24 solution activity.
th
Hanoi, 27 , October, 2006
E-Bank team
31/31
