NIB - Functional Upgrade Benefit Assessment - Sep 2016 v1.0

TEMENOS T24™
Functional Enhancements & Value Proposition

for T24 Upgrade R10 to R16
NIB, Ethiopia
September 2016
Information in this document is subject to change without notice.
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.
Copyright 2007-2008 TEMENOS Holdings NV. All rights reserved.

Functional Assessment for NIB
Table of contents
Document History ........................................................................................................................ 4
Introduction ................................................................................................................................... 5
Functional Upgrade Assessment ................................................................................................ 5
NIB Roles and Responsibilities throughout the Upgrade Assessment ................................. 6
Functional Drivers for the Upgrade ........................................................................................... 6
Business Solution Review – recap .............................................................................................. 7
Guiding Principles ........................................................................................................................ 7
Pain Points ..................................................................................................................................... 8
Local Development..................................................................................................................... 16
Functional Value Proposition Highlights................................................................................ 17
Arrangement Architecture ...................................................................................................... 17
Customer ................................................................................................................................... 19
Merging Duplicate Customer Records .................................................................................. 33
Capture deleted IHLD / INAU Records................................................................................ 34
Role Based Home Pages .......................................................................................................... 36
Introduction of User Roles ...................................................................................................... 36
Multiple Posting Restrictions ................................................................................................. 37
Standing Orders ....................................................................................................................... 39
Teller Till Limits by currency ................................................................................................. 40
Use of HVT ................................................................................................................................ 41
IBAN .......................................................................................................................................... 43
Trade Finance............................................................................................................................ 44
Loan Origination ...................................................................................................................... 45
Limits and the Introduction of Group Limits ...................................................................... 45
Treasury ..................................................................................................................................... 50
Introduction of mixed Limit structures (revolving and non-revolving) .......................... 51
Inactive Account Marker ......................................................................................................... 53
Collateral Allocation ................................................................................................................ 54
Potential New Licensed T24 Products ..................................................................................... 55
AA Preferential Pricing ........................................................................................................... 55
Functional Value Proposition, NIB Only

2
AA Agent/Broker ..................................................................................................................... 56
AA Rewards .............................................................................................................................. 57
Transaction Recycler (RC) ....................................................................................................... 58
Temenos Connect Mobile Banking ........................................................................................ 59
Temenos Connect Internet Banking (TCIB Retail)............................................................... 62
Loan Collections ....................................................................................................................... 67
Analytical CRM ........................................................................................................................ 68
Mandate Management............................................................................................................. 69
Temenos Payment Suite (TPS)................................................................................................ 71
IFRS ............................................................................................................................................ 72
Business Alerts.......................................................................................................................... 72
Provisioning .............................................................................................................................. 72
Service Level Agreement for Loan Origination ................................................................... 73
Fixed Assets .............................................................................................................................. 74
Standard Upgrade Approach Options .................................................................................... 75
Recommended Approach for NIB............................................................................................ 76
Next Steps .................................................................................................................................... 77
Next Steps for NIB ...................................................................................................................... 77

3
Document History
Author Version Date
Jude Roy Jaideep V1.0 29th Sep 2016
ABBREVIATIONS
Abbreviation Description
AA T24 Arrangement Architecture
AML Anti- Money Laundering
FX Foreign Exchange
HVT High Volume Transaction Processing
IBAN International Bank Account Number
IFRS International Financial Reporting Standards
LC T24 Letters of Credit
LD T24 Loans and Deposits
MD T24 Miscellaneous Deals
NAB Non-Accrual Basis
PD Past Due
TCIB Temenos Connect Internet Banking
TFS Teller financial Services
RC Transaction Recycler
TPS Temenos Payment Suite

4
Introduction
NIB are currently using T24 R10 in production and are investigating the benefits of an upgrade to T24 R16
release.
The Upgrade Assessment service is one of a growing range of “Productised Services” which we offer to
help our customers optimise their use of our products and increase their return on investment in Temenos
software.
By having a better understanding of all the benefits and new opportunities the latest T24 Release brings,
the bank will be better placed to identify new business functionality and increased value from the upgrade
and new version of T24.
During the Functional Upgrade Assessment session we reviewed the functional enhancements and new
features delivered by Temenos at T24 R16.
The list of functional enhancements to existing T24 applications in the NIB product suite that will be
provided by upgrading to T24 R16 are available in the supporting PowerPoint document “NIB - Upgrade
Assessment Functional Value Proposition - Sep 2016 v1.0” and the key highlights, benefits, recommended
approach and next steps will be reviewed in this document.
Functional Upgrade Assessment

The scope of this Business Solution Review for changes to T24 from R10 to R16 additionally also provided
an update on latest R16 features that would help NIB to improve its processes and customer services.
As part of the Assessment there were discussions with the following NIB Business teams:
o Retail;
o Corporate;
o Credit;
o Treasury;
o Finance;
o Operations;
o Internet Banking
o IT
In these sessions current Business overview and existing Pain Points were discussed together with
potential solution options and functional benefits/enhancements.

5
NIB Roles and Responsibilities throughout the Upgrade Assessment

 Support planning & co-ordination of Workshops and Interviews on proposal from Temenos
 Providing suitable executive level support from NIB during the entire engagement
 Providing NIB Process Know How (engaging Subject Matter Experts for different process areas for
participation in Workshops and interviews).
 Providing all relevant information on our consultants request
 Reviewing the output report from the assignment promptly and ensuring stakeholders are briefed
in preparation for the Upgrade proposal
The Overall Goal was to review new product functionality and the potential opportunities it gives NIB for
extending and optimizing its use of T24; removing reliance on local development (where feasible) and
reducing known pain points.
The Assessment itself and supporting output will enable NIB to analyze further and begin to determine
their business/functional priorities to feed into the overall Upgrade plan based on an understanding of
the target benefits, scope and approach to upgrading to T24 R16.
This workshop was delivered the week of the 5th Sep 2016.
Functional Drivers for the Upgrade

From a functional perspective the focus was primarily on:
• Move out of extended maintenance;
• Potential to address/remove current Pain Points;
• Focus on a move “Back to Core” and delivering a more integrated solution and improved customer
experience;
• Benefit from the functional enhancements delivered from R10 to R16;
• Be on the latest release of T24 – consistent with Temenos Product Strategy;
• To get maximum value from the software.

6
Business Solution Review – recap
 Discussions to review the major areas of change to be delivered as part of the

Key Activities
move to T24 R16
 Provide a roadmap of New Features and Business Solutions that can be
implemented with R16
 High level discussion on the local customisations in place at NIB and suggest
approach to move close to core T24 where possible
Exit Criteria /  Value Statement for upgrading specific Functional Areas
Key Outputs
 Functional input to the overall consolidated high level roadmap showing the
main steps in the upgrade approach, which can be used as the basis of a
high-level project plan
Guiding Principles
After the initial Kick off discussions it is clear that NIB:
1. Wants to move out of extended maintenance;

2. Wants to see most of its business pain points being addressed by upgrade to T24 R16
3. Wants to benefit from functional enhancements to existing T24 applications;
4. Will want to remove local development and rely more on core T24 function where possible;

7
Pain Points
During the Workshop activities pain points were discussed with each NIB business area.
Whilst the objective of the Upgrade Assessment is not to solve all of these, there is an opportunity
presented to review these items.
Based upon that review some may need further Temenos Helpdesk analysis; some may be solved by
upgrading existing R10 applications to R16 and others may be resolved by investing in new functional
opportunities at R16.
This document outlines the main pain points that could be potentially addressed by the upgrade:
1) Functional for Asset classification of overdraft, temporary overdraft Accounts is not available in
T24.
Potential Solution:
T24 R16 Retail Accounts (AR) support the overdraft aging functionality. Once an account is in the
ageing process, T24 provides the events to trigger Notification letters to clients for the overdraft
and Charges for the notification letters.
The LIMIT Property class has been enhanced to include configuration to place an account into the
aging process. The application ACCOUNT.OVERDRAWN.HIST allows the ACCOUNT.OVERDRAWN
record to be written to history once the overdraft has been cleared.
2) NIB is handling the Provision manually by using excel sheets and collateral Mitigation is also
manually performed.
Potential Solution:
T24 R16 Provision (PV) module can be considered by NIB to handle their provision requirements.
T24 PV Modules standard provisioning functionality supports:
Classification of Assets based on perceived risk
Calculation of Provision
Manual adjustment of Classification and Provision amount
Posting of the Provision amount
Collateral may be used to mitigate the amount of Provisioning.
3) The AA module should be reworked to daily pop up unauthorized activities done by users. T24
to show activities that are not authorized.
Potential Solution:
Unauthorized activities can be seen from the enquiries provided in T24 Model Bank. NIB can also
achieve this by a customized report in R10.
Alternatively, NIB can consider to implement loan origination as part of the R16 upgrade that uses
PW (Process Workflow) & SLA (Service Level Agreement) module to highlight the pending tasks
that breach the defined completion cut off time.
4) There must be additional field on limit menu to input number of collaterals, to avoid missing
inputting of required collaterals. The user updates the collateral codes in LIMIT record, but
forgets to create COLLATERAL records. T24 still allows the loan to be disbursed. So, NIB wants
T24 to raise an error if the collaterals are not created.

8
Potential Solution:
The fields COLL.REQD.AMT or COLL.REQD.PRCNT in LIMIT application can be potentially used to
control minimum collateral amount or percentage required as Collaterals in fixed type limits.
This field is used for defining the collateral required amount or percentage for the collateral code
specified in the multi-value set. If collateral required amount is less than the collateral provided,
then an override is generated during the utilization of the limit.
5) Total commitment shouldn't be removed on arrangement table for overdue contracts; this
helps to avoid reopening of loans and advances when overdue.
Potential Solution:
During R16 upgrade project, NIB to review the T24 AA model bank lending screens. Total
Commitment amount is now available in R16 Model Bank AA Lending Overview screens.
6) T24 allows overdrawing of accounts when the overdraft facility is expired. T24 raises override
but the user can approve the override. NIB wants to change the "unauthorized overdraft"
override in to an error message.
Potential Solution:
NIB can set up T24 Override class. During the input of a transaction, T24 can request the user to
override a certain condition, e.g. an account is overdrawn or has a posting restriction. The
overrides are recorded on the transaction so that the authorizer can view all overrides
encountered during input. The system administrator can set up restrictions so that certain
overrides can only be approved by specific user (Branch manager or supervisor). Alternatively,
NIB can change this override message in to an ERROR message, by set up in OVERRIDE application.
But, doing so will change this override message in to an ERROR message in all T24 applications.
7) NIB wants to check the balance of account on which loan repayment (using FT or TT application)
is being deducted. It helps to check whether the customer has sufficient amount in his account.
NIB expects to check the balance of the debit account during transaction input.
Potential Solution:
T24 AA Repayment screen using FT application raises override message to inform the user that
the debit account is not having sufficient funds to process the debit amount. The override
message will also display the amount that will be overdrawn from the account. Alternatively, NIB
can attach an account balance enquiry that will automatically pop up when the user inputs the
debit account number. This is possible by using T24 CONTEXT.ENQUIRY application.
8) T24 is not able to handle provisioning and related reports for AA Loans, AC Accounts.
Potential Solution:
T24 R16 Provision (PV) module provides enquiries PV.PROVISION.SUMMARY,
PV.CUSTOMER.DETAIL, PV.ASSET.DETAIL that can be used by NIB to check provision details.
9) T24 doesn’t allow definition of inactive months for accounts as per Domestic manual. NIB wants
to have different "Inactive" months set up for current, savings accounts.
Potential Solution:
T24 R16 ACCT.GROUP.CONDITION application allows the definition of "Inactive" months based on
account group. NIB can use this parameter to set up Inactive months for each account type.
10) T24 does not allow input of PL accounts in Teller screens

Potential Solution:

9
T24 TELLER.TRANSACTION parameter table can be configured to allow input of PL accounts in the
TELLER deal.
11) Teller Denomination - In R10 the Teller application allows the transaction to continue, even if
the denomination entered by the teller is not matching with the transaction amount.
Potential Solution:
T24 AUTO.DENOMINATE field in TELLER.TRANSACTION can be used to allow T24 to automatically
update the remaining transaction amount that teller has not entered manually. If this feature is
turned off, then T24 will raise an error message if the denomination details is not matching with
the transaction amount.
12) FCY Cheques for Collection - there is no screen available in T24 to register the FCY Cheques.
Potential Solution:
T24 R16 Model Bank provides the Menu option to process foreign currency cheques.
The menu option is available under "Cheques for Collection".
13) FT for Money transfer - Adjustment problem for FCY account in relation to exchange rate. No
field available in T24 FT screen to input exchange rate.
Potential Solution:
T24 Funds Transfer application provides the fields CUSTOMER.RATE and CUSTOMER.SPREAD.
These fields can be used to manually input the required exchange rate. NIB can review the FT
version used by the user and check if these two core fields are available in the version.
14) Upon registering incoming LC on T24, the system collects charges from customer’s account but
doesn’t generate debit advice (print - 900) for the charges.
Potential Solution:
When charges are defined in the LC with the CHARGE.STATUS field set to "2", T24 Model bank has
been configured to generate outward debit advice for the charges (900 Print). As part of the
upgrade project, NIB can review the delivery set up.
15) Import Collections - Option to input Local reference number at the issuance stage. This
reference number to be reflected in the advice and the reports.
Potential Solution:
T24 LC application contains the field OLD.LC.NUMBER which is mainly used for migration while
moving from old banking system to T24.
NIB can potentially use this field to store the local reference number and this field value should
be mapped in various T24 SWIFT set up tables like DE.MESSAGE, DE.MAPPING, and
DE.FORMAT.PRINT.
Please note that if OLD.LC.NUMBER is populated then it will be mapped automatically in
corresponding SWIFT (e.g. 700)
16) Import Collection – T24 does not has the functionality to generate debit advice.
Potential Solution:
T24 R16 Model Bank generates debit advice (900) when the charges are defined with charge
status "2". Further, Model bank is already preconfigured with following EB.ACTIVITY and
EB.ADVICES.
• LC-1201 Inward Collection Opening

10
• LC-3201 Inward Collection Sight Payment

• LC-2201 Inward Collection Amendment (Int)
• LC-2202 Inward Collection Amendment (Ext)
• LC-2203 Inward Collection Acceptance
• LC-2204 Inward Collection Closure
• LC-2211 Inward Collection Tracer.
• LC-2212 Inward Collection - Non-Pay/Non-Acc
• LC-2222 Inward Coll. Amendment - Trust Release
17) Under letter of credit, even when partial shipment is effected, T24 releases 100% margin to
customer.
Potential Solution:
NIB to check if the field FULLY.UTILIZED in the LC version is set to NO.
If the field FULLY.UTILIZED is set to YES then the full margin will be released by T24.
18) FT Cheque Number if wrongly input, user has to reverse the FT. But the user is not able to reuse
the previous wrongly input cheque number for the same customer. Also, when FT DRAFTS is
wrongly processed, user is not able to reverse the FT.
Potential Solution:
T24 allows the FT to be reversed and the Cheque number to be reused, as long as the cheque
number and Cheque type are input in the core fields CHEQUE.NUMBER and CHEQ.TYPE. T24 will
update the cheque status in the new application CHEQUE.REGISTER.SUPPLEMENT. After reversal
of the FT and when the same Cheque number is used again for the same customer, T24 will raise
the override "Draft/Cheque was already cancelled". User has to ensure that the Cheque number
is correct and can take a decision to proceed or not to proceed with the transaction.
19) FT allows the user to input cheque number of some other customer. T24 allows the transaction
to proceed. NIB expects T24 to raise a warning when cheque number of other customer is used.
Potential Solution:
T24 will raise the override message "CHEQUE NUMBER xxxxxxx NOT IN REGISTER", if the entered
cheque number does not belong to the Debit account's customer. The user would be required to
verify if the entered cheque number is correct. Also, NIB can set override class for this warning
message, so that only authorized supervisors can review such transactions and approve the
override.
20) If FT has gone to history, the user is not able to access the record to reverse. Historical Reversal
of FT is not possible
Potential Solution:
T24 allows the History reversal of FT by a set up available in the parameter table
FT.TXN.TYPE.CONDITION. Field HIS.REVERSAL to be set to YES, for FT transaction types for which
history reversal of FT is required.
21) The system does not check the margin held balances itself nor adds back to the account balance
during LC settlement before sending out an error message as “Insufficient Fund” on LC screen.
Potential Solution:
T24 R16 Trade Finance support netting of provision amount against the DR settlement amount.
The remaining is then taken from the customer.

11
22) T24 should be able to monitor and report loan delivery time (LDT). Time taken to disburse or
approve a loan.
Potential Solution:
NIB can consider to use T24 Loan origination using Process work flow (PW) and Service Level
Agreement (SLA) modules.
23) The module should have a reporting section for a monthly outstanding and settled export LCs
of a corporate customer.
Potential Solution:
T24 R16 Model Bank is delivered with various role based home pages required for different
department in the bank. The role based home pages available for Trade finance officer /
supervisor can be used to check these enquiries.
24) CIB - Difficulty of creating all accounts under one CIB user ID when the customer have various
CID. In NIB, many Customer records are available for a single physical customer. As a result
when the bank creates Internet banking ID for that individual, problem is faced as his account
and transactions are spread across multiple customer IDs.
Potential Solution:
As part of the upgrade project, NIB can identify such duplicate customer records available in T24.
T24 allows to merge the duplicate customer records to the identified original customer record.
NIB can also set up duplicate check parameters in T24 by specifying selected Customer fields for
duplicate check. Once this set up is done, T24 will raise a warning message whenever a new
customer record is created that matches with another customer record.
25) The system does not have options to view or display subsidiary ledger balance (Sub account
balance) of various internal accounts based on transaction dates as and whenever required by
the user.
Potential Solution:
T24 has a new method of handling such high volume accounts by using the concept of HVT (High
Volume Transaction Accounts). NIB can consider to change all their Sub accounts in to HVT
accounts as part of the R16 upgrade. T24 HVT functionality can also be extended to Normal
Accounts as well.
26) The system requires three processes namely Limit Setup, AA Arrangement creation and AA
Disbursement in order to effect granting fresh loan to a customer. However, the system
overlooks these processes and contrarily accepts loan repayment for loan arrangement where
disbursement was not made. Automatic Disbursement and Automatic Repayment
functionalities are not available on AA loans. Disbursement currently managed using FT
application, when partial or full amount is to be disbursed.
Potential Solution:
Disbursements in AA Lending could now be automated through payment schedule definition and
customer account could be credited using PAYOUT.RULES definition.
Payment types “DISBURSEMENT.AMT” and “DISBURSEMENT.%” is used to define scheduled
disbursements in Payment schedule record. For scheduled disbursement, BILL.TYPE in
PAYMENT.SCHEDULE should be kept as DISBURSEMENT.
Alternatively a PW process can be set up, to monitor the pending tasks more effectively.
27) FT - The system allows debiting customers’ account’s twice with the same cheque number.

12
Potential Solution:
User can enter the cheque number in the T24 FUNDS.TRANSFER core field CHEQUE.NUMBER. The
entered cheque number will be validated against the new R16 application
CHEQUE.REGISTER.SUPPLEMENT. When the same cheque number is used for the second time,
T24 will generate the override message "CHEQUE NUMBER xxxxxx ALREADY PRESENTED".
28) On DD screen, the system bypasses input control over value date of draft issued to a customer.
This means that the system can accept past or future date as a valid data entry.
Potential Solution:
T24 allows the bank to control the Maximum allowed forward and backward days using the set
up available in FT.TXN.TYPE.CONDITION parameter. If the value date entered in the FT screen,
exceeds the maximum allowed days, then T242 will raise an override message. Also, T24 will
default the Debit and Credit value dates to TODAY's Bank date when the fields are left blank.
29) Lack of data fields in T24 Customer application for capturing various values like Employee name,
allowances, taxable income, various deductions etc.
Potential Solution:
NIB can consider to use the new customer fields available in T24 R16 model bank like customer
salary, net monthly income and net monthly out to address this requirement.
30) The system does not display deposit of foreign currencies kept by branches in the denomination
of FCY instead it displays the foreign currency value in terms of local currency.
Potential Solution:
T24 R16 Model Bank Teller enquiries "Cash Position by Till", "Cash Position by Currency" and "Cash
Position by Denomination" can be used. The Enquiry "Cash Position by Denomination" shows the
till position in the respective currencies along with denomination and balance available in each
denomination.
31) T24 FT Account Transfer screen does not reject when same account is used for both debit as
well as credit side.
Potential Solution:
T24 raises the error message "SAME DEBIT AND CREDIT ACCOUNT" when both the debit and
credit accounts are same in FT application. NIB can set override class for this override message
and provide permission only to specific user to review and approve or reject such transactions.
32) Accessing previously captured signatures through the new branch company code has become
difficult on the system. Customer signature captured in Branch 1 cannot be accessed / viewed
from branch 10.
Potential Solution:
T24 Image management application IM.DOCUMENT.IMAGE can be used to store Customer
Signatures. This is available in the R16 Model Bank menu "Signature Capture" under Account user
menu. Signatures captured using T24 CUSTOMER record ID as the image reference, can be viewed
across all branches.
33) T24 does not support updating of daily exchange rates of foreign currencies on the system.
Potential Solution:
NIB can consider to use Reuters Datascope Interface available with Temenos gpack.

13
This interface acts between T24 and Reuters Datascope server. It is responsible for sending
request file (XML format) from T24 system and receives the response file from Reuter server.
Based upon the response file (CSV format) OFS message formed and the prices details are updated
in corresponding applications.
34) The system does not display authorized signatures of employees at the time of approving
transaction or based on the need to display the signature with a function key.
Potential Solution:
T24 R16 model Bank FUNDS.TRANSFER screens provided under the "Payment Services" menu to
process foreign Currency draft, Outward Remittance, Inward Remittance and Account to Account
Transfer shows the Signature captured for the Debit account entered in the transaction screen.
Also, NIB can use T24 Mandate Management functionality, if the bank is looking to define
authorized signatories for corporate accounts based on amount slabs.
35) T24 does not have capability of online tracking for returned checks due to insufficient fund in
the customer account balance.
Potential Solution:
T24 Model Bank supports this functionality. If a cheque is to be returned, then, by entering ‘YES’
in the RETURN.CHEQUE field on FUNDS.TRANSFER, it automatically returns a cheque, taking the
payment from a return suspense account as set in either the CQ.PARAMETER or
ACCOUNT.PARAMETER. The account that the transfer was originally to have been from is then
stored in DRAWN.ACCOUNT, which is found on both the FUNDS.TRANSFER and STMT.ENTRY
applications.
Cheques can also be marked as returned in the application CHEQUE.REGISTER, by manually
entering the cheque numbers in field RETURNED.CHQS.
T24 R16 Model Bank Enquiry "CHQ.RETURNED" can be used to view the returned cheques.
36) The T24 application does not properly interface with SWIFT system and as a result it has become
difficult to send branch LC data to SWIFT section through the system.
Potential Solution:
T24 allows the branches to send the SWIFT messages to the SWIFT network using SWIFT alliance
Interface. NIB can consider to use this package as part of the R16 upgrade project.
37) Account - The system does not have an option to display saving and Demand account category
balances along with their corresponding interest rates applied to each individual customers
within the category. NIB wants to have a report that shows the list of customer accounts and
the Credit / debit Interest applied.
Potential Solution:
NIB can refer to the T24 Model Bank enquiries "STMT.ACCT.CR" and "STMT.ACCT.DR" enquiries,
that provides the details of Credit and Debit interests posted for accounts and their respective
period balances.
38) T24 Guarantee application does not generate or produce customer advice on guarantee issue
operation.
Potential Solution:
T24 Model Bank has been 9configured to generate messages like 900 Print message for the debit
of charge and Cash margin, MT760 SWIFT message for Guarantee Issuance, 2320 PRINT message

14
for Guarantee Confirmation during the "Issue of Generic Guarantee", "Issue of Shipping
Guarantee".
39) Unable to reuse the reversed T24 DRAFT number i.e. after reversing the issued draft (FT) T24
doesn’t return the draft to stock.
Potential Solution:
T24 allows the Draft issued to be cancelled (Reversed) using the model bank versions. When such
cancelled drafts are reused, T24 will raise an override message "Draft/Cheque was already used",
to alert the user to check if the entered draft number is correct.
User can use the application CHEQUE.REGISTER.SUPPLEMENT or the T24 Model bank enquiries to
check the status of drafts.
40) The system allows end users to login and process transactions during holidays, after office hours
and on Sundays. Thus, the system is accessible by users any time out of the normal office hours.
Potential Solution:
T24 R16 USER application allows the Bank to define ALLOWED.DAYS, DAY.ST.TIME, DAY.END.TIME
that will control the user access in to T24. ALLOWED.DAYS field is used to specify the permitted
days and the period for which users can access the system is taken from the associated fields
DAY.ST.TIME and DAY.END.TIME. The values allowed are 1 to 7 meaning 1 MONDAY, 2 TUESDAY
and 7 SUNDAY.
41) T24 TELLER fails to validate signatories based on withdrawal limit set by the account holder's
owner.
Potential Solution:
T24 R16 supports mandate management functionality for TELLER application and a field
SIGNATORY is introduced in TELLER to validate and allow the user to capture the required
signatories.

15
Local Development
Based on the high level discussion:
 NIB is having a local development to do collateral valuation online. A new T24 service
BNK/COLLATERAL.ONLINE.REVALUATION is introduced, which can be run manually or at specific
intervals for revaluation/recalculation of collaterals.
 NIB had a local development for provision calculation and for calculating the provision after
considering the Collaterals available. During Assessment workshop, NIB mentioned that, this
development did not work as per NIB’s expectations and eventually NIB stopped using this
development. T24 Provision (PV) Module can be used for the purpose of Classifying, Calculating,
posting Provision entries. PV module also considers the collateral allocated before arriving at the
provision amount. Also, after the T24 PV module classifies the asset, an opportunity is provided
to the user to review the system classification and if required, user can change the classification
manually. T24 R16 also supports the functionality of Overdraft aging for AA Accounts.
 NIB is using a local solution to upload the Bills in to BL.REGISTER.

T24 R16 has some enhancements around the upload of Bills. The details of the invoices can be
recorded in a spread sheet (saved as a ‘.csv’ file) and uploaded into T24.
BL.REGISTER record is created for each invoice. At the time of upload, option is available to
perform duplicate check. The product type can be automatically assigned to each BL Register
based on user defined conditions. Option is also available to automatically batch the BL registers
based on user defined conditions. A new table BL.BATCH.CONDITIONS is introduced to define
conditions to update the product type in BL Registers created out of the same upload reference
and also to batch them.
The above represents an initial high level review and we would expect a more detailed joint analysis
review to take place as part of the transition from Upgrade Assessment to upgrade project.
In summary there is potential here to reduce the reliance on the number of existing locally developed
routines.

16
Functional Value Proposition Highlights
Please note that all functional enhancements to existing NIB licensed T24 modules from R10 to R16 will
be available as part of the move to T24 R16.
However each NIB Business area will need to review the changes pertinent to their operations, prioritise
and determine the approach to enable these enhancements to be made available to the Users in the NIB
production environment.
Some key changes detailed below:
Arrangement Architecture
Flexible payment schedules with automated payment calculations based upon both standard and non-
standard (e.g. seasonal) frequencies.
- Annuity, Instalment, interest only
- Ad hoc user defined schedules
- Season schedules
- Can be based on relative dates i.e. First repayment 60 days after drawdown
Flexible disbursement schedules

Multiple scheduled or ad hoc disbursements
Automated settlement instructions for disbursements or manual disbursement of available funds
Fully automated processing for billing, receivables, repayments and past due
- Supports concept of billing / invoicing
- Optional automated settlement based on customer instructions with automatic retry (see transaction
recycler)
- Payment by bill or by outstanding element i.e. interest first then outstanding principal
- Payments in advance
- Overdue processing based on billed amounts
Limits and Document / Image linked to AA can be viewed from the AA overview screen itself
AA Narrative can be taken to account statements.

This new Narrative field is Available in AA.ARRANGEMENT.ACTIVITY when you perform a new activity for
the Arrangement.
Simulate Arrangements and Compare

Simulate and compare the arrangements on a single screen and print the comparison results.
Loan enquiry for Limits and Collateral
View the Limit and Collateral information of the customer in the Arrangement Overview screen.
Flexible charging
- Scheduled
- Activity and Restriction based including deferral

17
Renewals with rules to control which conditions can change

- Change of Product
- Resetting of Product Conditions
- Rollovers
Minimum Payment Amount

Specify the minimum amount to be repaid for a property or an entire bill.
Tax on Interest
Apply tax on any charge or interest, include tax on annuity payment and Pro-rata method to determine
tax at the time of Repayment.
Rate Change Set in Advance

Banks can now inform the customers of changes to their interest rate and the revised payment amount
details well in advance of the actual periodic reset date.
Bill Settlement in Advance
Based on the advance payments, the bills now can be generated in advance and the number of instalments
are skipped to match the remaining amount.
Minimum Payment Amount
Users now can specify the minimum payment amount by bill type.
Payment Tolerance
Option to set the tolerance by bill type and the tolerance is now considered in a total settlement.
Interest Payment in Advance
The banks can now pay the total interest amount in advance at a predefined date.
Pay-off Tolerance
Now manage the payoff tolerance as an absolute amount or a percentage of the full payoff amount.
Amortisation until renewal of product date
Now Charge / Periodic charge income / expense can be amortised until the product renewal date
SWIFT Message Support
AA can generate following SWIFT messages:
MT320
- New Arrangement (When Term is defined in the contract)
- AMND type 320 is generated when there is an amendment to the term of the contract
- ROLL Type MT320 is generated when a rollover of the contract is made
- MATU type MT320 is generated when the contract is due to mature
MT330 – Deposits New Arrangement (When term is not defined)
MT350 – Generated When a contract has an interest payment schedule defined the next schedule of
interest will generate this message.
MT935 – Change of Interest

18
Pre Notification Advices

For the Product Lines Lending and Deposits the system can be configured to produce an Activity Pre
Notification Advice XX days before the event is triggered.
Currently supported Model bank pre notification advices are:
- Change of Loan principal interest
- Change in deposit interest
- Cancellation of deposits or lending
- Maturing arrangements
- Rollover of Deposits
- Change of Loan schedule
Customer
The introduction of the Single Customer View screen and new Person Entity records and Customer
Relationships helps deliver operational efficiencies and improved customer experience.
Delivering operational efficiency, prospecting function and the ability to capture a more complete
customer relationship picture in T24. Coupled with the Single Customer View this reduces costs and
increases operational efficiency by providing a single view of integrated customer data. The user no longer
needs to switch between different systems to aggregate customer data and assimilate the same.
Customer satisfaction is also increased as they are served better, faster and most importantly – accurately.
Overview:
Using the CUSTOMER.RELATIONSHIP table it is possible to build up a picture of complex relationships of
your customers with individuals or entities whether they are customers of the bank or not.
This information could be used to see how much risk is associated to the bank to a particular corporation
even if it is not a customer of the bank.

19
Scenario:
The diagram below shows the multiple relationships of several customers of the bank and how they are
linked to an Ultimate Holding Company. This scenario will be entered into the system showing the
relationship for Customer Y, Customer X, and the prospect Customer W.
Steps:
Create PERSON.ENTITY records for the following
 Micro Computers Ltd - ENTITY with the STATUS field set to None
 Associated Holding Company A - ENTITY with the STATUS field set to None
 Associated Holding Company B - ENTITY with the STATUS field set to None
 Corporate Prospect Customer W with the STATUS field set to Prospect
 Solicitors - ENTITY with the STATUS field set to None
 Director - PERSON with the STATUS field set to None
 Customers X and Y are to be created with a status of ACTIVE, and once authorised the system
will create CUSTOMER.RECORDS on hold. Authorise these 2 customer records.

20

21

22

23
When the status of these records is set to Active CUSTOMER records are created on hold. Once the KYC
checks have been completed they should be authorised. Notice the customer record id's have been updated
in the CUSTOMER field on the PERSON.ENTITY records above.

24
The customer records are shown below, information from the PERSON.ENTITY records have been used to
create the customer records and the PERSON.ENTITY record id is mapped to the field PERSON.ENTITY.ID
in the customer record.

25

26
The following records would need to be created in the CUSTOMER.RELATIONSHIP table to set up the
actual relationship matrix in the system.
For Customer X relationships
Create a CUSTOMER.RELATIONSHIP record linking the Solicitor 2006 and Director 2005 to Customer
111687. The ORIG.PARTY is CUSTOMER and the ORIG.PARTY.ID is the customer number. The REL.PARTY
sub values are multi valued to enter the details of both the solicitor and the director details
 ORIG.PARTY.1 is CUSTOMER
 ORIG.PARTY.ID.1 is 111687 the customer number for Customer X
 REL.PARTY.1 is Entity
 REL.PARTY.ID.1 is 2006 which is the ID to the record in the PERSON.ENTITY table.
 RELATION.1 is the id to the relevant record in the RELATION table.
 Enter the details for REL.EFF.DATE.1, RES.BRANCH.1 and RES.DEPT.1
The enter the details for the Director in the second sub value set
 REL.PARTY.2 is Person
Create a CUSTOMER.RELATIONSHIP record Linking Company B 1003 to Micro Computers Ltd 1001, as
neither are actual customers of the bank the PERSON.ENTITY records will be used.

27
 ORIG.PARTY.1 is Entity
 ORIG.PARTY.1 is the ID from the PERSON.ENTITY table 1003
 REL.PARTY.1 is Entity
In order to link customer X 111687 to the holding company B, create a CUSTOMER.RELATIONSHIP record
using the above two records. This enables the reuse of records in new relationships as they are identified.
In the example CR1215100121 below, the field ORIG.RELATION and CR1215100035 are used to create the
relationship.
 ORIG.RELATION is entered as CR1215100120
 REL.RELATION is entered as CR1215100035
 Enter the relevant information in the fields REL.EFF.DATE, RES.BRANCH and RES.DEPT for the
relationship

28
For Customer Y
Create a CUSTOMER.RELATIONSHIP record linking Customer Y 111688 to the solicitor record 2006.
In order to link customer Y to the Associated Holding company, create a CUSTOMER.RELATIONSHIP record
using CR1215100031 as the ORIG.RELATION field to CUSTOMER.RELATION CR1215100035 created earlier,
thus demonstrating the reusability of records.
For Customer W
Even though Customer W is still a prospect it is possible to create relationships for them.
Create a CUSTOMER.RELATIONSHIP record linking Customer W to the Solicitor 2006

29
Create a CUSTOMER.RELATIONSHIP record linking the Associated Holding Company A 1002 to Micro
Computers 1001
Create a CUSTOMER.RELATIONSHIP record linking Customer W 1008 to the Associated Holding Company
1002.
Overview:
The application PERSON.ENTITY is used to enter the details of entities or individuals who are not
customers of the banks. This application can therefore be used for the management of Prospects.
Scenario:
A prospect approaches the bank to open a current account. Before a customer record is created the bank
must complete KYC checks. Until then they remain a prospect. The prospect in the case is an individual.
Steps:
Open a record in the application PERSON.ENTITY, using the new record button
For an individual, enter the following details commit and authorise the record.

30
The fields PERSON.ENTITY, NAME and STREET are mandatory.

The fields LEGAL.ID, LEGAL.DOC.NAME and REG.COUNTRY are used in the creation of records for entities
only.
As the prospect passes through the KYC process the status on this record can be amended to reflect this.
From prospect the status is amended to Enrolment

31
Then to active
When the record is authorised with a status of active a Customer record is opened on HLD. The customer
number is updated in the CUSTOMER field
The new customer record can then be updated with additional customer information.

32
The process is the same for an entity, but the record should be flagged as an entity rather than a person
and the fields LEGAL.ID, LEGAL.DOC.NAME and REG.COUNTRY should be input and the field GENDER
becomes no input.
Merging Duplicate Customer Records

There are two ways in which duplicate CUSTOMER records can be merged:
1. When duplicate records are discovered on entry/amendment, an override is generated by T24
stating that the record is a possible duplicate.
2. If the override is accepted with no further changes to the record, the records are
automatically merged. On the Duplicate record, the field Merged To is updated with the original
record key and the field Merged Status will automatically set to "Merged".
3. On the original record, the duplicate record key are appended to the field “Alt Cus Id”.
The Merged To and Merged Status fields hold the details of the merging of customer records.
The screen shots below show how the duplicate record (left) and the original record (right) are
referenced to each other after merging.

33
Capture deleted IHLD / INAU Records

T24 has an option to capture the deleted records based on the set up in FILE.CONTROL for the related T24
application.
An Enquiry VIEW.DELETE.HISTORY is provided to view such deleted records.
Following screen shots, show a Customer record created and in INAU status.
After the record is deleted, the customer record will be written in to the CUSTOMER$DEL file and the
same can be viewed using the following enquiry.

34
The Deleted transaction record will hold the user name who deleted the transaction and also the date
time of the delete event.

35
Role Based Home Pages

Workspaces for defined users’ roles and aligned with business processes. System is more user friendly and
interactive, thus increasing productivity - guiding users’ actions, allowing them to work more efficiently.
Providing users with targeted, real-time information, improving service delivery.
Can be used as a navigational dashboard.
Retail example:
Introduction of User Roles

Permissions and rights can now be assigned to roles rather than directly to users, which means that the
whole group of users who perform the same task will have a single role
The concept of user roles (EB.USER.ROLES) is introduced and the functionality of this enhancement is
described below:
 EB.USER.ROLES is a new application in which all the relevant application restrictions for the
Roles are defined. For E.g. On creating a role record TELLER all the access permissions applicable
for teller will be mapped.
 Dispo and Override processing can also be specified under a Role.
 One or more roles can be directly mapped to a USER record under each Company.

36
 However USER can have either legacy SMS set up (application/version or user sms group directly
mapped to USER) Or Roles (EB.USER.ROLES). Both SMS restrictions and ROLES under USER
cannot co-exist.
 USER.SMS.GROUP can be mentioned within EB.USER.ROLES.
 A user logins with a default role, where more than one role exists for that user. The default role
is the first Role defined for that user. (Similar to Default Company login process).
 A user can switch roles using a utility defined under TOOLS menu in Browser.
Benefits
Permissions and rights can now be assigned to roles rather than directly to users, which means that the
whole group of users who perform the same task will have a single role. This can be mapped to the
bank's organizational structure so that the users can be assigned with a different role if they physically
change their roles in the organization.
Roles can also be mapped to users outside T24 in dedicated identity management or access control
systems. The role will be propagated into T24 along with the user credentials in order to specify the
user’s capabilities within T24. This enables the bank to manage what a user can do for many systems
without changing anything in T24.
Multiple Posting Restrictions

T24 POSTING.RESTRICT can be used to configure different types of posting restrictions.
Multiple posting restrictions can be set up in the T24 CUSTOMER and ACCOUNT applications, as shown
below:
When a Customer having multiple posting restrictions is used in debit or credit transactions, the following
override message will be displayed:

37
Also, it is possible to set up DEBIT restrictions for an account group using ACCT.GROUP.CONDITION, which
can partially cater to SHB functionality of restricting an account CATEGORY for Debit postings.

38
Standing Orders
For BO type of Standing orders, the field PER.OVER.CAB may be defined which determines the amount to
be transferred, by applying the % value on the Amount arrived at after deducting the Current Balance
amount defined for the STO from the Cleared Balance maintained in the Account.
For example if a BO type STO is created for an Account with Working Balance of USD 20,000 with the
following values:
PER.OVER.CAB = 20
CURRENT.AMOUNT.BALANCE = 10,000
Then the Transfer Amount will be calculated by the System as below:
Transfer Amount = (20000 – 10000)*20% = 2000
An amount of USD 2000 will be transferred from the above STO Account to the Counterparty Account as
per the defined frequency.
For FI type of STOs, the field Priority Number may be defined which determines the order in which the
particular STO will be processed during Batch process. This will facilitate the processing of high priority
STO which falls on the same execution date in case of insufficient balance in the Account.

39
Teller Till Limits by currency

New functionality is available in T24 Teller that will allow the bank to configure Till Limits.
T24 Teller’s till limits functionality helps currency wise till level limits to be maintained in each till based
on setup in TELLER.ID.
The limits whenever breached by a teller transaction will raise necessary overrides.
The till limit can be set up based on Cash, Traveler Cheque CATEGORY codes, in addition to currency wise
limits.
In the below example, the transaction generates an Override, as the amount of the Traveler’s Cheque
exceeds the limit of AED 500 set up for the Till ID 1000, for the CATEGORY 10090.

40
Use of HVT
As transaction volume increases this high-volume account solution provides standard account
functionality in a seamless manner to the end user without creating additional accounts and avoiding
operational issues experienced whilst using sub-accounts.
Individual accounts are now flagged as high volume accounts, setting this flag will activate the new
processing to avoid concurrency issues.
All Account balances are now stored in the centralised EB.CONTRACT.BALANCE table, however balances
can still be maintained in the ACCOUNT record for backward compatibility for existing clients.
When to use High Volume Accounts
High volume accounts should be used where there are likely to be significant volumes of movements
generated across the account that need to be completed in as short a time frame as possible.
Possible candidates are:
 Internal accounts used for collection of TAX and Charges, these are frequently high
volume operations both online and as part of the COB
 Internal suspense accounts – bulk payments are frequently processed through individual
suspense accounts. For example a company salary payment batch will typically result in
a debit to the corporate account initially and a credit to a suspense account. Each ‘child’
payment is then made to the individual staff member by debiting the suspense account.
 Nostro accounts – where the bank needs to make a payment externally a Nostro
account is usually credited by the transaction issuing the payment. High volumes of
transactions can be processed both online and offline.
 High volume customer accounts – certain accounts owned by customers may also
process high volumes of transactions, both online and offline
Usage Details
There is a mechanism in T24 to enable high volume processing for accounts. The field HVT.FLAG in the
account record controls whither an account is high volume or not. A value of No or Null indicates that it
is not a high volume account. If this field is set to Yes it indicates that this is an account which has a high
volume of transactions every day.
As part of the Upgrade process Temenos will transition the bank from sub-account processing to the
HVT solution.

41
The following diagram explains the flow for high volume accounts
This functionality has been further enhanced at R16 allowing the parameterisation of High Volume
Transaction Accounts (HVTs) providing a parameter set-up at each company level to control the HVT
processing so that all or a specified category of accounts in a specific branch can be set to HVT.
The function offered replaces the existing sub-account processing, which has a number of operational
issues:
 Additional numbers of Account records being created. The sub-account records are
clones of the master account and are were held in the main account table. From an
audit perspective the existence of additional account can be difficult to justify.
 Each sub account is updated individually and maintains its own balance. As a result to
obtain the account balance requires summation of the related sub-accounts.
 Movements are posted to the individual sub-accounts, so in order to be able to produce
a full statement or enquiry view of the master account that includes all postings, all
movements across sub-accounts need to be merged.
 For client based accounts the sub-accounts need to be linked (using the compensation
account setting in the account table) to allow interest calculation on the total balance
and movement for the master account.
 In order to close a master account all sub-accounts must be closed before closure can be
requested.

42
IBAN
The International Bank Account Number (IBAN) is an international standard for identifying bank accounts
across national borders with a minimal risk of propagating transcription errors. It was originally adopted
by the European Committee for Banking Standards (ECBS), and later adopted as an international standard
under ISO 13616:1997. The current enhancement is to provide for Generation, Validation and Usage of
IBAN in T24.
T24 IBAN (IN) module can be used for the automatic generation of the IBAN number during the creation
of the T24 Customer accounts
T24 IBAN Module provides an IBAN structure table, to let the clients configure the position of various
elements in the IBAN account structure, as shown below.
During Account creation, T24 will use the IBAN structure defined in the above table to generate the IBAN.
The IBAN is updated in to the Account Alternate ID field.

43
Trade Finance
There have been some significant changes between R10 and R16 which extends the functional reach and
benefit.
During the functional review session we discussed the functional enhancements delivered between R10
and R16 for both the Letter of Credit (LC) module and Miscellaneous Deals (MD) module.
The review highlighted some key changes:
 The user now has the option of manual maturity of LC with option to enter exchange rate for
releasing outstanding provision amount and also manually mature usance drawings. (LC)
 More flexible charging function (LC & MD)
o At the time of issuance of Letter of Credit, commission can be calculated based on the
tenure of the LC and collected upfront or at a predefined frequency. The method of
calculation can be flat, band or level for amount as well as period (current pain point).
o Amortisation of charges;
o Charge refunds in full or in part;
o Charges can now be collected from the beneficiary/third party
 Feature introduced to link Shipping Guarantee to an Inward Documentary Collection
 Functionality now available that will shift the liability from Letter of Credit to Guarantee when a
shipping guarantee is issued.
 Option is Introduced to calculate cash margin (provision) either on LC Face Value or LC Liability
amount
 Trade Finance module has been enhanced to settle a single drawing under a letter of credit in
multiple instalments. A Drawing under a Letter of Credit can be settled in multiple instalments on
predefined due dates instead of creating multiple Drawing records. (LC)
 A new draw type, MX is introduced to support the feature of settling sight as well as
acceptance/deferred payment portions of a mixed payment type LC through a single drawing.
 The feature of reinstating a contract from LIQ status to CUR status is introduced and to allow all
actions that can be performed on a live contract (MD).

44
Loan Origination
Loan origination is the process by which a borrower applies for a new loan, and a lender processes that
application. Origination is a systemic and process defined model created using the PROCESS WORKFLOW
module. Origination process starts from creation of a lending prospect for a particular loan, processing of
the loan application based on the loan type selected and pre-disbursal of the loan. Since it caters to a loan
product, it makes use of support modules such as LIMIT and COLLATERAL. Each loan application is
monitored from the time it is entered into the system using a support module, SERVICE LEVEL
AGREEMENT (SLA) and tracked through the various work steps of credit review and approval. It also
uses the module for scoring.
The origination process comprises of 3 types of loans: personal loan, auto loan and mortgage loan. Steps
involved in originating a loan vary by loan type. The process can be initiated for a prospect or an existing
customer. Broadly Loan Origination comprises of 5 processes;
- Lending Prospect Onboarding
- Mortgage Loan Process
- Personal Loan Process
- Auto Loan Process
- Pre-disbursal Process
There are 2 users involved in the Loan Origination process:
- Retail Credit Officer
- Retail Credit Manager
Limits and the Introduction of Group Limits

The Limit module has some new expanded functionality.
Limit module has the ability to define a Limit sharing group in addition to the individual Limit. The Group
Limits are shared by a group of Customers which is setup for a specific combination of products and allows
a customer to be a member of more than one group.
Group Limits have the below features,
 Group Limits can be secured by attaching the Collaterals.
 It allows addition and Deletion of Customer and Product.
 A Customer should be allowed to be a part of more than one group and one group can have
multiple customers sharing the Limit. It is a many to many relationship.
 The above feature is also applicable for Products. The Products and Group have a many to many
relationship.
 All the current features of Individual Product limit are also applicable for Group Limits.

45
 Like an individual product limit, group limit will also be defined in Limit Currency.
Defining Intermediate cap in Limit amounts;
 Group Limits have the facility to allow intermediate cap amounts to be defined within a Group.
This intermediate cap can be defined by setting up a Sub Group (Child group) within a Main
Group and linking them accordingly.
 The sub groups are defined as normal groups but will have a Parent group set. Only one level of
Sub grouping is allowed.
Steps to create a Limit Sharing Group and link to Limits
 Individual Limits & Group Limits can also be created for Different currency which can be
different from the individual Limit Currency.
 Group Limits can be set with an Expiry date and processed similar to Individual Limits.
 Group Limits will always be provided in a Single Time band and multiple Time bands are not
supported.
Limits using Limit Sharing Group will also have the below standard Features of Limits like Individual
Limits:
 Limit Reducing Schedule and Increasing Schedule

46
1. Adding the schedule in Individual Limits will not add the schedule automatically in
Group Limit as they are separate Credit lines.
2. This needs to be explicitly added to the Group Limits. It can be for the entire hierarchy
including the Sub groups or can be set for a single Limit.
3. Allocation will be recalculated when the Limit is Reduced or Increased.
4. Process of allocating Collateral per contract will consider Individual and Group Limits.
 Limit sweeping will happen for Limits with Limit Sharing Group also and they can be swept to
Contingent Accounts for charging purpose like individual Limits.
 Group Limit allocation will be considered for Overdraft and Interest processing for the account
through ACCOUNT.DEBIT.LIMIT should consider Group allocation as well, provided the Group
customer Limit for Overdraft is set as a Single Limit.
 Special type of Limit Product created as CROSS Limit Product will not be allowed to be a part of
Group Limit product.
 Sub allocation process can happen within one group to another and also with Individual Limits.
 Group Limits will be considered in T24 standard Limit enquiry.
Reversal of Limit Sharing Group
Limit sharing group record will be allowed to reverse if below conditions are satisfied,
No Limit records have been created for the group.
No Sub group records exist for the Group.
All other functions are allowed.
Utilisation through LIMIT.SHARING.GROUP
The Group Limits are shared by group of Customers not in part of any Customer Liability group and it can
have a single product or combinations of products. Customer’s Liability can be covered by Utilising
Credit Limit granted through Limit Module. The Limit can be granted to - Own Customer - Group Limit in
which he forms a part - Both from Individual and Group Limit.
The Limit processing will utilise the Credit Limit from the Group Limits if the Customer is a part of the
Group.
Limit processing holds the utilisation at the below levels,
Sharing Group Level

47
Product Level
Product Customer level
Utilisation process takes care of satisfying any Intermediate Cap amount set through Sub Group
definitions. Sub Groups are more to define Intermediate Cap amounts and not for any Allocation
processing.
 Utilisation can happen directly to Group Limit even if there is a no Individual Limit set for the
Customer.
 Customer can participate in more than one group and can utilise more than one group to cover
single Liability.
 Allocation happens when the customer has more than one Sharing group.
Rules of Allocation are as below
 Ability to define the Allocation priority of utilising each group. This will decide the order of
utilisation of Limits for the customer.
 Option to utilise the Individual Limit based on the priority. Default priority should be to Utilise it
first.
Any removal of Utilisation should happen in the reverse order of the Utilisation priority.
Again, if there is no Priority set through this application then the allocation will happen as below,
 Individual Limit will be utilised first
 Group Limit will be utilised after that.
 Priority between multiple groups will be based on order in which they got created.
 Within a Group the order of allocation for multiple customers will be the order in which they
utilise. i.e. FIFO basis
Some rules for utilising Group limits
The Group Limits are allowed to be set only with Single Time band.
Group Limit functionality is enabled only for Retail products and below applications will not be allowed
to utilise the Group Limit.
 FX
 SC

48
 SL
 LC
 MG
 SW
 FR
 AZ
Group credit line (i.e.) product and Serial number should be same as the product specified in the
Utilising contract.
 If the Group in created at Global level then it will be combined with the Individual Limit only
when it is defined at Global Level.
 The same applies for Serial Number as well. Group credit line and Individual credit line should
match.
 This is applicable for multiple Groups for the customer as well. The entire group should have
same Serial Number and product Line.
 Group Limit can be created for a Single Product as well sharing multiple customers. In such case
there is not necessity to define the Group credit line as a Global line.
Benefits
This functionality will enable the client to define Group limits for a particular group of Customers and
also enables Banks to create Sub groups for providing Limit Caps to a specific group of Customers within
the Parent group.

49
Treasury
An option has been provided to allow banks to choose between MID.REVAL.RATE or REVAL.RATE for
revaluation of both Spot and Forward Contracts.
New functionality
Following optional features with regard to FX Revaluation and Present Value (PV) of the Mark to Market
(MTM) are added to the existing functionality.
 Ability to apply different rates for Revaluation of positions identified as TODAY, TOM and SPOT.
 Ability to reckon the discounting period either from Spot to Value date or from Today to Value
date within IFRS Accounting method.
 Ability to apply MID.REVAL.RATE to Spot Position revaluation even if REVAL.RATE is present.
 Provision to derive today’s Rate and populate the same in REVAL.RATE through a local routine.
 Provision for various combinations in applying revaluation rate and discounting.
SPOT contracts
For contracts falling within the spot period, the revaluation rate applied for TOM and SPOT varies. The
method of deriving the revaluation rate is as follows:
 For TOM positions, the revaluation rate is derived by adding/subtracting the premium (or)
discount for Tom Next (TN) to the Mid.Reval.Rate or Reval.Rate as the case may be.
 For SPOT positions, either the MID.REVAL.RATE or REVAL.RATE will be applicable as per the
Parameter set-up.
 For TODAY’s position (which is essentially AL position), a provision is created to populate today’s
rate in the field REVAL.RATE in CURRENCY record if the User requires. Today’s rate is derived by
adding or subtracting the Premium/Discount defined for both ON and TN to the MID.REVAL.RATE.
User is required to populate the rate in REVAL.RATE field by a local routine.
 Revaluation results on account of TOM and SPOT positions can be subjected to discounting to
find the PV.
Forward contracts
For positions whose value date is greater than spot date, the revaluation method remains the same as in
the previous functionality. When a Forward Position moves into Spot position, it will be dealt with as
explained above under Spot Positions based on the parameterization.
To cater to new functionality, the following fields are introduced/modified in the
REVALUATION.PARAMETER application. They are:
a. REVAL.WITHIN.SP (accepted values ‘Yes’ or ‘Null’) is introduced for the users to specify whether
the contracts within the spot period have to be revalued at different rates for TOM and SPOT. For
Today’s Positions (AL), option is provided to populate the derived rate in the field REVAL.RATE.
The value 'YES' triggers the new functionality.
b. REVAL.RATE (accepted values ‘Yes’ or ‘Null') is currently allowed only to multi value with APPL.ID
as FX.RB is also extended to FX.SP. This field allows the user to choose between MID.REVAL.RATE
and REVAL.RATE as the revaluation rate for SPOT contracts.

50
c. IFRS.DISC.PERIOD (accepted values are ‘SPOT’ or ‘TODAY’) is introduced to provide an option for
the users to perform discounting either from SPOT date or TODAY. This field accepts input only
when IFRS.REVALUE is set to ‘Yes’. This works independent of the set-up in REVAL.WITHIN.SP.
Note: Post installation of this enhancement, for Users upgrading from lower releases to R13 or above, the
values in REVALUATION.PARAMETER would be converted to 'Yes’ in case of REVAL.RATE for FX.SP and
‘Spot’ in case of IFRS.DISC.PERIOD.
Based on the above fields and permitted values, the following options are available for revaluation and
discounting. They are:
a. Revaluation of Tom and Spot positions at same rate and no discounting
b. Revaluation of Tom and Spot positions at different rates and no discounting
c. Revaluation of Tom and Spot positions at same rate and discounting period from SPOT date for
Forward position and no discount option for Spot position
d. Revaluation of Tom and Spot positions at same rate and discounting period from Today for both
FWD and SPOT positions
e. Revaluation of Tom and Spot positions at different rates and discounting period from Spot for
Forward positions and no discount option for Spot position
f. Revaluation of Tom and Spot positions at different rates and discounting period from Today for
both Spot and Forward positions
REVAL RATE in CURRENCY Record

Currently REVALUATION.PARAMETER provides an option for Forward contracts to take either Reval.Rate
or Mid.Reval.Rate for Revaluation. Option is available to choose REVAL.RATE for SPOT contracts also.
Note: When a Forward contract moves to Spot period, the originally defined value for FX.FW will only be
considered until its maturity.
Introduction of mixed Limit structures (revolving and non-revolving)

Limit can now have a mixture of Revolving and Non Revolving Limit in the same hierarchy. It will allow
the definition of a Non Revolving Limit under a Revolving Parent Limit.
There is a limitation on this functionality, that a Revolving Limit cannot be defined under a Non
Revolving Limit Parent.
To clarify further:
 If the Parent product is Revolving, then Child reference can either be Revolving or Non Revolving
 If the Parent product is Non revolving, then Child reference can only be Non revolving.

51
This will be allowed for all products including the Global Product Limit. When Reducing Limit is repaid,
the repaid portion will be used by other products of the Limit structure, subject to the availability of
overall limit.
Allowing the Reducing Limit under a Non Reducing Parent will allow the facility to reuse the repaid
portion.
Reuse – In the below setup any repayment made in the Loan Limit will only reduce the Loan Limit and
will not reduce the Parent Limit, as it is Revolving. This setup needs to be used when we want to reuse
the repaid portion of the Non Revolving Limit.
No Reuse – In the Below example, any repayment made in Loan Limit will not only reduce the Loan
Limit, but also that of the Parent Limit, as it is Non Revolving. By this we can achieve the "No reuse"
option of repaid portion of the Non Revolving Limit.
The Summary of Limit type and usage of Non Revolving and Revolving Limits within a Limit hierarchy is
illustrated in the table given below.

52
Child Limit Parent limit Type
Revolving Revolving Allowed
Revolving Non Revolving Not Allowed
Non Revolving Non Revolving No Reuse
Non Revolving Revolving Reuse
Benefits
The repaid portion of a Non Revolving Limit can be utilised by other Limits in the group, subject to
availability of overall Limit.
As part of the Upgrade a review of the current Limit structure is recommended at which point the
integration of the above detailed new function can also be analysed.
Inactive Account Marker

T24 now allows the bank to have the Inactive Months set up both in COMPANY level and also in the
ACCT.GROUP.CONDITION record.
If the definition in the ACCT.GROUP.CONDITION is not available, then T24 will use the default set up from
COMPANY record for marking the accounts as Inactive.

53
Collateral Allocation
T24 is enhanced to specify the Allocation amount for a specific contract. This allocation amount is only for
Reporting purpose and is allowed only when the contract is attached directly in Limit reference of
COLLATERAL.RIGHT.
Collateral application is enhanced to allow COLLATERAL.RIGHT to specify Allocation amount. Two new
fields ALLOCATION.CCY and ALLOCATION.AMT are added to existing versions:
 COLLATERAL.RIGHT,INP
 COLLATERAL.RIGHT,INP.HP
 COLLATERAL.RIGHT,INPUT
ALLOCATION.AMT: The user can specify the allocation amount under Allocation Amount field. This is
allowed only when the contract is specified directly.
ALLOCATION.CCY: This field is defaulted by the system based on the contract ID.
In addition the user can now define a priority for the allocation of collaterals when given to third parties
and when received from third parties.

54
A new parameter CO.ALLOCATION.PARAMETER is introduced in the Collateral application to setup the

default sorting order for the limit and collateral allocation. Also, the sorting order can be defined in which
a:
 Limit should receive cover from the collaterals in case of multiple collaterals attached to it
 Particular collateral needs to be allocated for multiple limits
This application can be used to set the priority order at various levels. The system makes use of this
application to decide the order of priority while allocating the collateral to the liabilities.
This new functionality facilitates the bank to define priorities for allocation of multiple collaterals to single
limit liabilities. The order may be to utilise own collaterals first with third party collaterals given. It may
also be sorted based on the asset type or Customer id. It is also possible to define this priority at the
system level, or company level or customer level.
Potential New Licensed T24 Products
AA Preferential Pricing
Preferential Pricing is part of the Retail Banking suite of products.
The PR module provides various methods for financial institutions to attract and retain customers by
offering preferential pricing based on the relationship a customer maintains with the bank or the channels
through which the customer accesses and transacts on their accounts.
Preferential Pricing comes in various formats. These can be condensed into four main pricing strategies:
 Relationship Pricing
 Customer Segment Pricing
 Channel Pricing

55
 Promotional Pricing
These strategies could be used independently of each other or in combination depending on each use
case.
Relationship Pricing
Preferential Pricing is used primarily by financial institutions, such as banks and credit unions,
Relationship-Based Pricing is a competitive pricing model. The pricing strategy is based on segmenting
customers into groups and determining the profitability of the customer. Based on that profitability, banks
set their prices for services. It is an effort to reward loyalty and build long-term relationships in an
increasingly competitive market.
It is based on the various relationships that a customer maintains with the bank. It refers to both the
relationship and customer characteristics (e.g. customer segmentation) that the bank wishes to employ.
For example, eligibility for relationship pricing plan could be based on:
 Customers Age (e.g. Minors, Senior Citizen)
 Customers’ salary, if customer salary is greater than $200,000 then he is eligible for High Net
worth Individual (HNI) Relationship plan.
 Loyal Customer (i.e. length of relationship with bank)
 Customers Sector (If sector equals to 1002(staff) then he is eligible for a Staff Relationship
pricing plan, If the sector is equal to 1001 (Individual) then he is eligible for HNI Relationship
Pricing plan etc.,)
AA Agent/Broker
Agent, a financial product line where the terms and conditions agreed between the institution and the
agent are defined as a product under the Agent product line and a separate arrangement is created for
each Agent. This solution is an end to end commission processing functionality that includes calculation
and claw back functions. These functions in AA, provides a framework for retail brokerage requirements
across the Lending & Deposits product lines.
The eligible products per agent are defined in the property class PRODUCT.COMMISSION. When agents
generate new retail business from their customers, a financial arrangement is created under the relevant
product line. At the financial arrangement level, fields are available to capture the agent’s ID and the
arrangement ID. The agent’s commission events are defaulted in AGENT.COMMISSION (a property class)
within the financial arrangement. In AGENT.COMMISSION, users can negotiate the default commission
calculation.

56
This is included as it could potentially support the bank’s internal incentive scheme to sell products.
AA Rewards
Rewards is part of the Retail Banking suite of products.
The Rewards functionality addresses multiple areas of client concern:
 Increase Customer retention in an increasingly fluid and commoditised market.
 Inducements to customer behaviour, for example in providing regulatory information, changing
interaction patterns to reduce bank costs.
 Incentives to increase client wallet (and loyalty) share through encouraging involvement in
additional products.
 Improves bank’s profiling / customer intelligence facilities by increasing client involvement with
bank.
Loyalty programmes have been adopted in multiple industries for the above reasons, with the
increasing commodification trends in the banking industry, there are compelling reasons for banks to
wish to have a loyalty program.
Financial institutions compensate customers by means of points, based on the terms and conditions
agreed between them. The calculation of the points can happen online along with a business event
(such as deposit funding, loan disbursement, cash withdrawal and so on) or it can happen at regular
intervals (for example monthly). The points collected could be internal loyalty points of the bank or
points of external providers. The points would be defined as a simple currency inside T24.
The client would then be able to spend these points.

57
The RW module is a financial product line where individual terms and conditions are agreed between
institutions and customers. This Reward functionality in conjunction with the AA framework provides for
loyalty reward requirements to be linked with the existing Lending, Deposits and the Accounts product
lines.
Transaction Recycler (RC)

Transaction Recycler provides the ability to retry failed financial transactions at regular intervals. This
retry mechanism is currently restricted to handle IC and AA transactions.
Retry of failed transactions would be done using a recycler T24 service, which would run as a COB job in
a specific stage both during END.OF.DAY and START.OF.DAY. This job would retry the transactions on
scheduled dates until the transaction is settled or number of retry attempts allowed have been
exhausted or retry end date is reached.
During each retry recycler would take the amount available in the settlement account for settling the
transaction amount in full or partial based on the recycler retry configuration setup.
The prioritisation rules are for sequencing the pending transactions for a given Settlement Account.
There are three linked tables, used to set up the priority in RC Module:
RC.PRIORITY - Ranks transactions by EB.SYSTEM.ID
RC.PRODUCT.PRIORITY - Ranks by product within an EB.SYSTEM.ID
RC.CONTRACT.PRIORITY - Ranks at transaction level

58
Temenos Connect Mobile Banking

 Temenos Connect Mobile Banking (TCMB) is the Retail Mobile Banking solution developed using
edgeConnect.5.3
 Supports SmartHybrid apps which are developed once and wrapped with native skins for specific
phone types.
 Provides best in class design incorporating usability, accessibility and security.
 Possibility to change the entire UI without interfering with the processes
 Inline refreshing of components presentation
 T24 Enquiries and version are same as that of TCIB Retail
 Integrates with T24 using IRIS
Following are some screen shots of T24 TCMB:

59

60

61
Temenos Connect Internet Banking (TCIB Retail)
Key features of the TCIB are listed below:
Home page
Greeting Message – (Your name, last login date/time and number of unread messages) summary
of all the financial products held at bank with balances. This includes:
Viewing the mini statements (last 5 days statement)
View loans
View and create term deposits
Link to manage payees
Create Accounts
Display / change your personal details / change preferred language
Change the Password (The 'Change the password' feature is supported if 4TRESS 7 Self-Service
Portal is connected to the Retail solution.)

62
Secure messaging
Inbox
Sent items
Read message
Reply to message
Compose new message

63
Accounts Page
Account balances, Recent transactions, Transaction history, Upcoming payment (view and
cancel), Search for transaction, Download transaction history and Print statement
Transaction Search
Search for a transaction using “statement Period” or “Date Range”.
View recent transaction (Last 60 Days)

64
Make a payment
 Make a payment between your accounts
 Make a payment to a beneficiary ( UK / International)
 Make payment to a company or organisation (Utility payments)
 View exchange rates
Option to choose payment frequency

 Pay Immediately
 Pay at a future date
 Recurring payment (Standing Order)
Manage Standing Order and Direct Debits

 View existing STO / Cancel existing STO
 View existing DD / Cancel existing DD

65
Cheques
 Cheque status / Stop payment
 Request for cheque book
Loans
 Loan Overview
 Loan repayment schedule
Alerts
View and subscribe for alerts (based on system configuration)

66
Manage Payees
Create a new payee (UK / International)
Edit/amend an existing payee
Delete a payee (both local clearing and utility companies)
Make a Payment
Loan Collections
The functionality of T24 Collections (CL) is based principally on the overdue debt records held in the Past
Due or AA overdue component in T24. The debt collection is available for all loan products in T24 Lending
Suite, handled through the AA or LD module.
When a borrower defaults on a due payment, the unpaid item will be taken over by the overdue
processing component (in AA or PD) and will follow an aging process (buckets). These buckets will segment
collection items in different stages of case-handling.
Irrespective of the number of products and overdue payments and amounts, a delinquent customer has
to be classified in one class and any collection or recovery action should be based on the global customer
position and not by product or payment. Therefore Collection Items (records generated by the system
when a customer defaults on a loan) are based on the customer’s ID, and not individual AA/LD Contracts.
All accounts in arrears for a given customer are placed under the same collection item collectively and are
dealt with as such.
When a collector pulls a customer from a queue for follow up (no other collector should work on the same
customer before it is released by the first collector), the worked record has to be stamped with a pre-
defined action code (how communication was established) and an outcome code (the item’s status)
describing the activity of the collector and the result of the action respectively. Some outcome codes can
generate an automatic future outcome code; For example a promise to pay (PTP) can generate a kept

67
promise to pay (KPTP) or broken promise to pay (BPTP) outcome code. This will be based on the
customer’s actions from the date the collection item was updated to the outcome due date agreed upon.
Based on the outcome code, the worked record must either be re-queued in the same queue but with
different priority or to be transferred to another queue for further action, that is, PTP (Promise To Pay),
transfer to field collection, external agencies or no further action to be taken status. This is dependent on
the criterion of the queues defined.
Once the customer has no leftover items in arrears, they would disappear from the collections queues
until the customer defaults again, at which point they will be again placed into an appropriate queue to
be worked.
Analytical CRM
Opportunity and Campaign Management
Opportunity and Campaign Management enable the bank to offer appropriate products and services to
clients, and handles the methods through which the sales and origination processes are delivered.
The CRM module in T24 will help the Bank to define a set of criteria to select Customers to whom it plans
to sell its new product. Once Customers are identified, the bank can initiate a workflow to sell the product
to the identified Customers. This workflow can be constructed using the Process Workflow (PW) module
in T24. CRM also enables a Bank to provide probability scores. It means, once a set of Customers qualify
for a campaign, the Bank can predict the probability of certain Customers availing of the loan is higher
than that of others.
Customer Profiling
Profiling is used to group customers of similar classification. It may be done either through T24 analysis
of customer data ('T24-driven profiling) or as an update from an analytic engine, such as Insight.
Calculations from either source can also be manually overridden.
When using T24-driven analysis, the system automatically populates the field CR.PROFILE.TYPE and
CR.PROFILE with appropriate values, as well as the CR.CALC.PROFILE value.
For the T24-driven profiling, there are 3 applications which are involved in this process, they are as
follows:
CR.PROFILE.TYPE
CR.PROFILE
PW.TRANSITION
The alternate method for populating the Customer Profile is manually or from a separate T24 table (which
in turn is probably updated through an internal use of EB.FILE.UPLOAD). If the separate T24 table is used,
this is indicated on the CR.PROFILE.TYPE, specifying where (which field and table) the information is taken
from.
It is possible to do automatic profiling using an online service called CR.PROCESSING.
We can also prevent profiling for a customer by setting the field NO.UPDATE.CRM of CUSTOMER
application to YES.

68
Mandate Management
Mandates can be set for a Corporate Customer using this option. This will contain information on
signatory groups required for authorisation of transactions up to a specified amount.
Currency of the mandate, Mandate amount, Signatory Group and the number of signatories under each
group can be recorded. The ID of the record is Customer Number followed by date (the date can be
either today or a future date) and the sequence number.
This option can be used to amend an existing mandate if the date is greater than or equal to today.
Sample screenshot shown below
Then the Mandate has to be recorded with information on Signatory Groups required for authorisation
of transactions and the mandate amount allowed for each group. Finally the Mandate id should to be
linked to the Corporate Customer record or to the account of the customer for activation.
Signatory Group:
The Signatory group for a Corporate Customer can be created using this option. The signatory customers
linked to the group should be specified along with validity period (start/end dates).
Sample Screenshot shown below

69
Option is available to link the Mandate to an existing Customer or Account. While linking the Mandate,
it is possible to specify the transaction application for which the mandate checking is applicable.
Currently, this facility works for applications FUNDS.TRANSFER, STANDING.ORDER, DD.DDI and
BULK.STO. If no application is specified, then it would be applicable for all allowed applications.

70
Temenos Payment Suite (TPS)

Credit Transfer Batches
Logical batch is collection of payments characterized by a single debit and multiple credits. Salary batch
is an example of such a logical batch.
Some of the characteristics of a batch payment are as below:
 The contents of a batch file will always have one debit party and one or more credit parties.
 The debit party is termed as the ‘Parent’ and the credit parties are termed as the ‘Children’.
 Every payment in the batch file will have a common reference called GBI or Global Batch
Identifier which is used to differentiate between many batch files received at the T24 bank.
 Parent or the debit party is always on the bank’s book maintaining a T24 account. Children or
the credit parties may or may not be maintained in the bank’s book.
 The credit parties can have an account with
o The same bank as the debit party. This results in a ‘Book’ transfer
o Another bank in the same country. This results in in the payment instruction being sent
out via a Local Clearing house.
o Another bank in a different country. This results in in a SWIFT payment.
 If the parent has insufficient funds, then the whole batch is parked for manual funding or put to
repair based on configuration in TPS.
 Before applying fees for the parent, all the children are processed for fee charges first. This is to
apply all unconditional charges of the child to the parent. Hence, the parent is held at fees
processing until all the children are processed for fee calculations.
Flexible handling of account restrictions

In TPS, during Account validation, if the debit account or the credit account have any restrictions set, then,
Debit Party Determination (DPD) and/or Credit Party Determination (CPD) will throw appropriate errors
based on the response from the Account and customer interface routine.
It is flexible to handle errors from Account and Customer interface based on configuration as
 “Error” - Raise a Non-Functional error and route payment to manual repair queue
 “Warning” - Raise a warning and move it to the FIAT queue if the warning exists for the debit
account. Raise warning and move payment to the manual repair queue if warning exists on the
credit account. A repair operator can then accept the warning and continue with payment
processing
 “Skip” - Ignore the restriction and continue processing the payment. (Applicable only via API
hook routine).
 Blank – No restrictions on the account.
Audit trail is updated with following responses:

71
 In case of errors and warnings, audit trail is updated with event type as “ERR” or “WAR”.
Warning text returned from the DDA is stored in “Additional Info”.
 In case the response received is ‘Skip’, audit trail is updated with event type as “INF” (only
applicable for hook).
IFRS
Supporting the IFRS framework. Offering Categorization of assets and liabilities; Valuations using
amortized cost; Valuations using Fair Value; Annual Disclosure; Impairment of Assets; Reclassification of
Assets.
Hedge accounting component of IFRS9 already available.
Published Product delivery strategy to deliver the Effectiveness Calculator by early 2017.
Business Alerts
Financial institutions need to monitor events happening in the various systems that they run, including
the core banking system.
Such events by nature are of interest to either the financial institution themselves or their Customers.
An event could have any number of consequences. Monitoring can be used to either feed a Business
Activity Monitoring system or even used to send an Alert (typically Email or SMS or even as a T24 Secure
Message). Such Alerts will normally have been requested by one or more persons.
There are 5 distinct stages in the life cycle:
Event Definition
Define Subscribers for the Event
Event Detection
Event Evaluation & Publication
Allow Request for Alert Notifications
Manage Requests
Event Logging
This in combination with the currently licensed Process Workflow (PW) application will deliver the same
function - aimed at grouping various businesses and banking procedures into a logical process of activities.
This grouping enables allocation of work to different users, ensuring vital tasks are not left out causing a
breakdown or delay in the process chain.
Provisioning
Use of this module enables classification and provision calculation flexibility based on either Standard or
IFRS Provisioning standards.
The PV Module supports classification, calculation, posting and manual adjustment of provision amount
for AA Loans and overdraft on Accounts (both AC and AR i.e. AA Retail Account).
The PV Module supports the following T24 Lending modules:

72
Arrangement Architecture (AA)

Retail Accounts (AR) Overdraft
Accounts (AC) Overdraft
Loans and Deposits (LD)
Money Market (MM)
Syndicated Loans (SL)
Payment Due (PD)
T24 PV Modules standard provisioning functionality supports:
Classification of Assets based on perceived risk
Calculation of Provision
Manual adjustment of Classification and Provision amount
Posting of the Provision amount
Collateral may be used to mitigate the amount of Provisioning.
The T24 rules engine allows complex asset classification rule generation. The product is compliant with
both Standard and IFRS provisioning requirements and with IFRS enables full impairment processing and
provision function.
Service Level Agreement for Loan Origination

A service level agreement (abbreviated as SLA) is a part of a service contract where the level of service is
formally defined. The business drivers for implementing SLAs include and cover both adherence to
external standards, and allowing differentiation through level of customer service. Banks are subject to
various codes setting minimum standards of good practice when dealing with consumers, business,
internal departments and organisations. Defining turnaround times (TAT) for process/activities and
monitoring of status in case of breach of SLA. The above functionality is handled by the SG module.
SLA’s (Service level agreement) are defined in Loan Origination based on the following criteria:
 SLA’s are defined at both PW.ACTIVITY and PW.PROCESS.DEFINITION levels. Inside
PW.PROCESS.DEFINITION, there won’t be any SLA defined for continuous activities.
 SLAs are defined based on internal and external interaction.
- Internal interaction is within the users in T24. For example: Timeframe set for workflow
“recommendation done by Credit Officer and Approval done by Credit Manager”.
- External interaction is with the customer. For example: Bank waiting for customer’s
document to proceed with the process.
Functionality of SLA in Origination
Retail Credit Manager would have an overview of status on all the processes. He would be updated on
the activities for which SLA is breached. This is displayed on his dashboard as an enquiry (given below).
Every time the duration time to complete an activity is breached, the activity details along with time
details, get displayed under the enquiry on the Retail Credit manager’s Dashboard. From here, the Retail
Credit Manager can reassign the activity to another user. For the activities with status as breached and
however got subsequently completed, a Red flag is displayed against the activity and for the activities
with status as Breached and not yet completed, a Green flag is displayed against the activity.

73
Fixed Assets
T24 Fixed asset solution allows an organization to keep track of details of each fixed asset, ensuring control
and preventing misappropriation of assets. It also keeps track of the correct value of assets, which allows
for computation of depreciation and other events including transfer, disposal and write off.
Currently only the accounting entries are captured in T24 all other operations are in a satellite system. By
using the integrated T24 solution this integration overhead is removed).

74
Standard Upgrade Approach Options

The approach to the functional side of the Upgrade first needs to take into account the agreed approach
to the technical side.
The technical “like for like” phase of the Upgrade will always be the key first step in any recommended
approach.
However after that we have a number of options to consider:
1) Undertake the “like for like” technical upgrade in full. Only adopting new business
functionality in a phased approach post go-live.
Benefits – quickest time to new release. Reduces scope and risk of initial upgrade.
Limitations – Business see no visible impact/improvement from the upgrade
project; unable to address any functional pain points raised; unable to
immediately benefit from the functional enhancements delivered between R10
and R16.
2) Undertake a full upgrade project, including technical “like for like” upgrade, exposing all
new business function to the user community, implementing new modules such as IFRS,
PV, TFS, DX etc.
Benefits – ability to make maximum benefit from functional enhancements and
new modules at R16. Business see immediate benefit. Many current pain points
addressed.
Limitations – increase scope and risk of the upgrade project. A longer timeframe
to realise potential benefits whether technical or functional.
3) A hi-bred approach - Determine what the functional priorities are whether delivering new
function or addressing key pain points and incorporate such priority changes within the
timeline for the technical “like for like” upgrade. Then post go-live have a phased delivery
approach to deliver other key, but less critical functional enhancements or new product
implementations.
Benefits – Key pain points addressed. Business see some immediate benefit. A
balanced risk approach. With further benefits to be derived.
Limitations – increases scope and risk of technical like for like for upgrade, but
only in a minimal way.

75
Recommended Approach for NIB

Based on the discussions during the discovery workshop, the key pain points raised and sharing of
pertinent information the recommended approach would be based upon hi-bred approach and include
the following steps:
1) Technical like for like Upgrade to be the starting point;

2) Determine priority for key Pain point resolution and implementing back to core
suggestions;
3) During or prior to this phase NIB to run evaluations of the priority potential new Products
/ new licensed function like:
 Provision (PV)
 Temenos Connect Internet Banking (TCIB)
 Temenos Connect Mobile Banking (TCMB)
 Service Level Agreement (SLA)
 Reuters Datascope Interface
 SWIFT Alliance Interface
4) Based on business priority determine a phased approach for exposing R16 enhancements
taking into account existing projects post upgrade to R16;
The benefits of the above approach are:

1) You will be on a later release of T24 – consistent with Temenos strategy;
2) Key Pain Points addressed as part of the initial phase;
3) Business Users can also be made aware of the phased roll out of either R16 functional
enhancements or new T24 applications;
4) The increase to the scope in comparison to a “like for like” technical upgrade is appropriate and
manageable;
5) Post upgrade landscape includes a plan to ensure maximum benefit from the enhancements and
new function delivered at R16. It is an enabler for future business and operational strategies.
Primarily based on the information received and the output from the Upgrade Assessment, NIB will be
able to undertake further internal review and analysis and then work with Temenos, or certified Upgrade
Partner, in terms of the planning to deliver a phased approach to implementing, training and using new
function to support the NIB business goals and growth strategy.
Based upon our experience Phase 1 would include:

 Technical Upgrade
 Key pain point resolution (to be selected by the NIB Business).
Phase 1 is an enable for Phase 2:

 Back to Core items (to be selected by NIB Business)
 Provision (PV)
 Temenos Connect Internet Banking (TCIB)
 Temenos Connect Mobile Banking (TCMB)
 Service Level Agreement (SLA)
 Reuters Datascope Interface
 SWIFT Alliance Interface

76
Next Steps
Based upon the Assessment workshops, discussions and this output document you now have a high level
understanding of the function and benefits that some key new solutions could deliver.
The next part of that process is for us to arrange more product specific demonstrations in order to ensure
that your business requirements are met by the corresponding solution. With that in please find outlined
below the recommendations:
1. Demonstration of TCIB / TCMB;
2. Demonstration of Provision (PV) Module
3. Should NIB decides to use the suggested new modules and functionalities, then training will be
required for new selected modules.
Next Steps for NIB

1. Provide feedback on this document. Seeking clarification where necessary;
2. Review in greater detail all the functional enhancements delivered between R10 and R16 to
determine the priority functional enhancements to be exposed to the users. This is primarily
a business function;
3. Consider the approach recommendations above and determine whether you are in
agreement with the suggested approach and confirm what components would be included in
the overall upgrade planning.
4. It is our recommendation that NIB considers to move from ARC-IB to TCIB, which is the latest
Temenos Internet Banking offering. We have a productised service that will assess the ARC-
IB implementation at NIB. This assessment will enable NIB and Temenos to understand the
efforts required to move NIB from ARC-IB to TCIB.
5. NIB are extensively using AA module and based on the discussions it is clear that most of their
issues are related to AA set up, which could be addressed by an AA training course. NIB can
consider to engage Temenos for AA Core, AA Lending Training courses as part of the upgrade
project.
All the above can be discussed further with your Account Management team and Upgrade specialists.
It is envisaged and expected that the upgrade planning will go through a number of iterations until it is
considered complete.
The upgrade scoping delivered as part of this Assessment will outline the estimates for the technical like
for like upgrade of your production environment. Once the scope and approach has been agreed for the
functional upgrade then further estimates can be prepared on that basis. This is expected to be a joint
exercise between NIB and Temenos.

77

NIB - Functional Upgrade Benefit Assessment - Sep 2016 v1.0

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NIB - Functional Upgrade Benefit Assessment - Sep 2016 v1.0

Uploaded by

Copyright:

Available Formats

TEMENOS T24™

Functional Enhancements & Value Proposition

Information in this document is subject to change without notice.

Copyright 2007-2008 TEMENOS Holdings NV. All rights reserved.

Functional Value Proposition, NIB Only

Functional Value Proposition, NIB Only

Jude Roy Jaideep V1.0 29th Sep 2016

AA T24 Arrangement Architecture

AML Anti- Money Laundering

HVT High Volume Transaction Processing

IBAN International Bank Account Number

IFRS International Financial Reporting Standards

LC T24 Letters of Credit

LD T24 Loans and Deposits

MD T24 Miscellaneous Deals

NAB Non-Accrual Basis

TCIB Temenos Connect Internet Banking

TFS Teller financial Services

TPS Temenos Payment Suite

Functional Value Proposition, NIB Only

Functional Upgrade Assessment

Functional Value Proposition, NIB Only

NIB Roles and Responsibilities throughout the Upgrade Assessment

Functional Drivers for the Upgrade

Functional Value Proposition, NIB Only

Business Solution Review – recap

 Discussions to review the major areas of change to be delivered as part of the

After the initial Kick off discussions it is clear that NIB:

1. Wants to move out of extended maintenance;

Functional Value Proposition, NIB Only

Functional Value Proposition, NIB Only

10) T24 does not allow input of PL accounts in Teller screens

Functional Value Proposition, NIB Only

• LC-1201 Inward Collection Opening

Functional Value Proposition, NIB Only

• LC-3201 Inward Collection Sight Payment

Functional Value Proposition, NIB Only

Functional Value Proposition, NIB Only

Functional Value Proposition, NIB Only

Functional Value Proposition, NIB Only

Functional Value Proposition, NIB Only

 NIB is using a local solution to upload the Bills in to BL.REGISTER.

Functional Value Proposition, NIB Only

Functional Value Proposition Highlights

Flexible disbursement schedules

AA Narrative can be taken to account statements.

Simulate Arrangements and Compare

Functional Value Proposition, NIB Only

Renewals with rules to control which conditions can change

Minimum Payment Amount

Rate Change Set in Advance

Functional Value Proposition, NIB Only

Pre Notification Advices

Functional Value Proposition, NIB Only

Functional Value Proposition, NIB Only

Functional Value Proposition, NIB Only

Functional Value Proposition, NIB Only

Functional Value Proposition, NIB Only

Functional Value Proposition, NIB Only

Functional Value Proposition, NIB Only

Functional Value Proposition, NIB Only

Functional Value Proposition, NIB Only

Functional Value Proposition, NIB Only

Functional Value Proposition, NIB Only