NIB_Technical_Changes

NIB Upgrade Assessment - Technical Changes from R10 to R15
New field LOGIN.STATUS has been introduced to check the login

status of a particular user
Enhancement in R11 of BANKING FRAMEWORK
Description:
New field LOGIN.STATUS has been introduced to check the login status of a particular user
Value Proposition:
New field LOGIN.STATUS has been introduced to check the login status of a particular user. Data in
this field will be used for the enquiry USER.STATUS.
Repeated Crashes at System level detected by tSM
Crashes at .LOAD/.SELECT stops the service. Repeated Crashes on the

same job within a time interval stops the service Duration and the
number to be configured at TSA.PARAMETER level.
Description:
Repeated Crashes at System level detected by tSM
Crashes at .LOAD/.SELECT stops the service. Repeated Crashes on the same job within a time interval
stops the service Duration and the number to be configured at TSA.PARAMETER level.
Value Proposition:
Repeated Crashes at System level detected by tSM crashes at .LOAD/.SELECT will stop the service.
TAFC Enhancements
Description:
The CALLJEE function is roughly equivalent to the JEEActivate function. However, it will connect to
the JRemote Inbound JCA if not already connected, send the request, and receive the response. The
first invocation of CALLJEE will attempt to open a connection to the application server. The following
environment variables are used during the open connection phase of the first call.
Value Proposition:
The CALLJEE function is roughly equivalent to the JEEActivate function. However, it will connect to
the JRemote Inbound JCA if not already connected, send the request, and receive the response.
EB.DICTIONARY enhancement to support the MB Translation
Easy to switch between different Languages using simple set up
Description:
Enhance EB.DICTIONARY, VERSION and ENQUIRY to support Model Bank Translation
This enhancement is to standardise the terms used in Model Bank configuration and build a
Dictionary of terms to facilitate easy Translation of Model Bank and maintenance of the translated
terms.
1) Expand EB.DICTIONARY to support translation of VERSION & ENQUIRY labels, headers and enable
the labels to be read from the compiled DICTIONARY of terms
2) Enhance the Language table in T24 to support up-to 99 Languages
Value Proposition:
EB.DICTIONARY enhancement to support the MB Translation
Easy to switch between different Languages using simple set up
Duration of the activity can be defined now in Hours as well as

minutes.
Description:
In R11, two new fields have been introduced. They are EXPIRATION.HOURS & EXPIRATION.MINS. This
field will help the user to define the duration in hours as well as in minutes. These fields are used for
reporting purpose only. The impact of the above fields can be monitored only with the help of the
enquiry.
Value Proposition:
Duration of the activity can be defined now in Hours as well as minutes.

Revisit already executed activities without the condition.
Description:
This enhancement will help to re-visit the already executed activities without any condition. Eg.
While creating the Customer record, Customer is suppose to give all the necessary documents. At
that point, if one of the documents was not submitted and later the customer comes and submits the
document. Then in that case we can use route to the already executed activity for amending the
details.
Once the process is initiated after completed the set of activities in a sequence the system will loop
back to the already executed activities infinitely. This pattern is called as Arbitrary Looping. This
pattern can be achieved by using the fields Pattern Construct, Route To Act and Route Act Status in
PW.PROCESS.DEFINITION.
This functionality definition can be disabled by setting NO to field USE.WORKFLOW.PATTERNS in

PW.PARAMETER.
Value Proposition:
It can be now allowed to revisit already executed activities without the condition.
Repeat Variant
Description:
This enhancement will help to re-visit the already executed activities based on a condition. If the
condition is true, the system will loop back to the already executed activities. This pattern is called as
Repeat Variant or Structured Looping. This pattern can be achieved by using the fields Pattern
Construct, Eval Condition, Route To Act and Route Act Status in PW.PROCESS.DEFINITION.

PW.PARAMETER
Value Proposition:
Repeat Variant or Structured Looping will help to re-visit the already executed activities based on a
condition. If the condition is true, the system will loop back to the already executed activities.
Recursion helps the process to execute a particular activity n number

of times.
Description:
In current release, recursion allows to execute a particular activity n number of times, based on the
given condition. The condition has to be attached in the form of routine to PW.PROCESS.DEFINITION
record.

PW.PARAMETER.
Value Proposition:
In current release, recursion allows to execute a particular activity n number of times, based on the
given condition.
Parallel Split
Executing two or more activity in parallel within a process definition.

Description:
The process can route to two or more parallel branches. Each of these activities should be defined in
the same PW.PROCESS.DEFINITION. Multiple activities can be executed in parallel within a process.
The activity which follows the parallel construct will be triggered only after all the parallel activities
are completed.
Value Proposition:
Parallel Split - It is now allowed to execute two or more activity in parallel within a process definition.
Exclusive Choice :
Executing one activity from the list of activities based on a condition.

Description:
The process can route to an activity from the given list based on a condition. At the time of execution
the process will trigger any one of the activity based on the value returned by the routine which is
attached. It provides the facility to execute the next activity in the process after any one of the
activity in list reached a specified status
Value Proposition:
Exclusive Choice - It can be now allowed to execute an activity from the list of activities based on a
condition.
Configuring T24 Services

Enhancement in R11 of COB & Online Services
Description:
T24 Services is now configurable based on the periodicity. This can be setup for individual records in
TSA.SERVICE with Format (Date Time Frequency(30/12/2011 15:00 1D)) tSM(Temenos Service
Manager) would check whether the specified frequency has reached and based on the data triggers
the service automatically.
Only Available for service control set as STOP
Once completed frequency is reset and manual intervention is not allowed. To be used for services
such as Archiving.
Value Proposition:
In older releases any services which has to be started required manual intervention in TSA.SERVICE
application by changing SERVICE.CONTROL field to START/AUTO.
From R11a new field(FREQUENCY) has been introduced using this option in TSA.SERVICE no human
intervention required for trigerring a service. TSM has now got the intelligence to verify and start a
service based on the frequency values specified for that particular service.
Performance Improvement
Description:
Caching across Multiple Transactions
Ability to process multiple messages/Applications in a single Transaction.
In prior releases Database operations were not cached across transactions.
Caching in R11 significantly Reduces interactions to hardware resources by 40%.
For AA transactions Facility available for usage with OFS.GLOBUS.MANAGER
Caching available as default for all bulk transactions.
Value Proposition:
Caching in R11 better utilizes the system hardware resources to deliver high performance in
Online/COB.
Browser Performance Improvement

Description:
No User validation for second successful & identical message OS.TOKEN & OS.TOKEN.USE will not be
updated for channel related transactions.
Value Proposition:
Frequent updation to OS.TOKEN & OS.TOKEN.USE has now been reduced and resources utilisation
will be minimal when updating these files.
TEC COB Enhancements

Description:
TEC Profiles T24 Activities
Includes database access as well as T24 application response. Packaged with IGNORE options
Overhead in TEC is avoided New METRICs are available.
Value Proposition:
Overhead in TEC is avoided & New METRICs are available which Includes database access as well as
T24 application response.
Transaction Bulking in T24

Description:
Bulk mechanism will allow input/authorisation to the core application and the additional tables in a
single transaction without affecting the template workflow. From the second message Updates to
PROTOCOL/RECORD.LOCK is no longer available.
Value Proposition:
Message processing is made simple and efficient with bulking mechanism to process more than one
transaction.
SELECT.AHEAD in COB
Description:
T24 has the ability to switch jobs in the same stage to utilize the idle time during single threaded
reports.
It breaks the traditional COB framework i.e., idle sessions during an earlier stage can be tuned to do
the selection of such jobs.
This facility has been extended to perform selection of jobs across stages to utilise agents idle time.
So this allows us to prepare List file pre-filled processing of these records which will be picked at
appropirate stages.
Can be used for local jobs and can be easily parameterized.

Value Proposition:
From R11 its now possible for jobs to do selection earlier than it’s configured stage. Whenever there
is an idle threads availability encountered, irrespective of the batch stage threads will jump ahead to
do just the SELECT part of a job at a different batch stage which fastens COB times and prevents any
idle threads existence.
Bulking records in COB

Description:
Bulking records in jobs is available with the new Service Framework implemenation. Bulking enables
a single commit to the database which reduces connection and driver overhead.
Value Proposition:
Prior to R11 F.JOB.LIST file is build with its own logic. From R11 Bulking of records can be
parameterised based on the specified values in the field(BULK.NO) which should be numeric and
between 1 and 200 as the maximum bulk limit is 200.
If bulking number is specified in PGM.FILE, data will be udpated to database in one single commit.
Which will reduces the driver overhead by using the resources efficiently
Traditional Cache Availability

Description:
Traditionally cache was not available for Close Of Business. In a nutshell ‘No difference between
WRITE and F.WRITE’. F.WRITE invoked WRITE directly no usage of T24 Cache and this was inside
Transaction boundary. Repeated Writes on same record resulted in multiple I/O.
Value Proposition:
After introduction to traditional cache in COB data updates to disk within the transaction boundary
can be either enabled/disabled in R11. Reason is any F.WRITE/WRITE functions in a batch job will not
be directly update data to disk but now with the usage of WRITE.CACHE common
variable(I_COMMON) this can be controlled in efficient manner.
Record Verification
Description:
Dynamic intelligence of the jobs to perform internal SELECT. Substitution of FILTER routines FILTER
routines run single Threaded Jobs to have dynamic intelligence to convert conditional SELECTs into
simple SELECT.
Record routines to return filtering ability of jobs
Ability of the job is updated at PGM.FILE.
Value Proposition:
R11 is equipped with Dynamic intelligence which will invoke jobs to perform internal SELECT & will
convert conditional SELECTs into simple SELECT. This will reduce the time taken by .SELECT for
performing conditional statements and based on the filtering logic record ids will be processed by
record routine. This framework change Provides improved COB performance.
Removal of Unnecessary locks

Description:
Close of Business frameworks holds locks for COB integrity. Locks are held on
F.BATCH.STATUS/F.LOCKING/F.JOB.TIMES/F.BATCH
slowing down the process even for jobs that were left idle COB Framework modified to absorb the
locks only when required Early detection of a job’s status available
Jobs that do ‘nothing’ finishes real fast.
Value Proposition:
Locking Overhead on core tables F.BATCH.STATUS/F.LOCKING/F.BATCH/ F.JOB.TIMES has been

condensed from T24TM R11 which has drastically improved performance in COB.
Performance Improvement
Description:
JobList Records distributed towards the end of job
Ensures that records that contain more than one transaction are split which balances the load across
agents which also ensures agents are not left idle. Distribution of records is proactively done and
broadcasted. The new ids are written with a suffix.
Value Proposition:
Batch Job Control(BJC) now has a unique behaviour to verify if there is any idle threads available
while executing Multithreaded COB routines. If the system finds any threads which is close to
completion but with more number of records then BJC will Distribute these ids across threads for
processing. This will provide enhanced throughput and reduces COB execution Time.
Performance Metrics
Description:
It is now possible to analyse the performance of a transaction, in a very detailed level, by activating
the jBASE performance metrics. This will provide information on the number of I/Os, calls made, time
spent per subroutine for every transaction processed by T24 either online or via a service. It can be
invoked by setting the OP.CONSOLE field in the SPF.
However switching on OP.CONSOLE is recommended only on test environments as it occupies more

space and occupies more CPU usage to capture information.
Value Proposition:
To identify performance of a particular application/transaction OP.CONSOLE can be enabled in SPF

which will provide detailed metrics information.
Records information such as number of calls to ther routines, time spent per subroutine for every
transaction processed by T24 either online or via T24 services.
Enhanced TSA.STATUS table

Description:
More detailed informaiton can now be obtained from F.TSA.STATUS live table. Details like Number of
Opens, Reads, Writes, Inputs, Executes, Deletes, Memory Usage and T24.Session.No.
Value Proposition:
1) TSA.STATUS live table now provides information on number of OPENS, READS, WRITES, INPUTS,
EXECUTES, DELETES,CLEARFILES and also the MEMORY Utililized for the particular agent will be
updated.
2) This table also provides information on the current agent with status values of the job that is
performed like ''Selecting Contracts'', Processing Contracts'', Managing Control List'', ''Selecting List
file'', and ''Processing Single Thread''.
Enquiry to verify USER login status

New Feature in R11 of COB & Online Services
Description:
New Enquiry to list Active Users(USER.STATUS)

Value Proposition:
Now to verify a status of a USER to identify if he/she is currently active enquiry USER.STATUS can be
used to provide precise information.
Promoted columns are being created to improve the performance of

‘expensive’ queries such that response times are reduced. The idea is
that certain fields in the XML document (corresponding to single value
Attributes in T24) can be promoted, i.e. duplicat
Enhancement in R11 of DATABASE ARCHITECTURE
Description:
Promoted columns are being created to improve the performance of ‘expensive’ queries such that
response times are reduced. The idea is that certain fields in the XML document (corresponding to
single value Attributes in T24) can be promoted, i.e. duplicated into a separate relational column, so
that it can be retrieved more quickly. In addition, an index can be created on the individual column to
further increase performance. The driver translates the JQL query accordingly. i.e., the driver will
create a SQL column expression instead of an XPATH query, which would have been used before to
select the field from within the XML document column.
Value Proposition:
Promoted columns are being created to improve the performance of ‘expensive’ queries such that
response times are reduced.
The BASE64 is a special type of file that has to be specified during the
file creation time, using the ‘NOXMLSCHEMA’ qualifier. There is no
specific environment NOTE: The performance can be evident only for
queries that are frequently used,since frequent
Description:
The BASE64 is a special type of file that has to be specified during the file creation time, using the
‘NOXMLSCHEMA’ qualifier. There is no specific environment NOTE: The performance can be evident
only for queries that are frequently used,since frequent queries will be fetched from the database
driver cache directly. variable associated with BASE64. Also there are no special procedures to follow
or special function to work with BASE64. It is just another type of file like BLOB or WORK type file.
Once the file is created using the appropriate qualifier the driver code manages the internal
representation of the data that is written and read to the DB2 database server.
Value Proposition:
The BASE64 is a special type of file that has to be specified during the file creation time, using the
‘NOXMLSCHEMA’ qualifier.Using this file type for frequently used enquiries will improve
performance
A time constraint can be set for executing a SQL query which is

submitted by the DCD driver. The maximum time in seconds can be
defined for all queries, and this will cause the summary termination of
the query and returns an error to the application once
Description:
A time constraint can be set for executing a SQL query which is submitted by the DCD driver. The
maximum time in seconds can be defined for all queries, and this will cause the summary termination
of the query and returns an error to the application once the time period has been exceeded.
The execution time of all the queries is logged in the driver log file
Value Proposition:
The maximum time in seconds can be defined for all queries, and this will cause the summary
termination of the query and returns an error to the application once the time period has been
exceeded.
This Enhancement bypasses the Justification of the attributes if

Extended Dict is present for the attribute. If the numeric value ‘101’ is
present in the Extended Dictionary it will do a numeric compare and
for everything else it will do a string compare.
Description:
This Enhancement bypasses the Justification of the attributes if Extended Dict is present for the
attribute. If the numeric value ‘101’ is present in the Extended Dictionary it will do a numeric
compare and for everything else it will do a string compare.
Value Proposition:
This Enhancement bypasses the Justification of the attributes if Extended Dict is present for the
attribute.
ARC Mobile - M-Commerce Application on XHTML

New Feature in R12 of ARCHITECTURE & FRAMEWORK
Description:
XHTMLPayment’ Channel is made available now
Value Proposition:
XHTMLPayment’ Channel is made available now in R12
ARC Mobile - T24 Push Schema to ARC Mobile

Description:
Whenever a new Mobile AA Product is proofed and published from T24, the AA Properties like
UI.BEHAVIOUR, USER.RIGHTS will be pushed to ARC Mobile via CALLJ(EE). The T24 also contains a
parameter that details the technical mobile channel which will be held in a new Property Class
"MOBILE.TECH.CHANNEL".
Value Proposition:
In the earlier releases, the schema from T24 is not mapped with the schema in ARC Mobile.
In R12, T24 PUSH Schema to ARC mobile is available
Force Dispo
New Feature in R12 of BANKING FRAMEWORK
Description:
Assume that a user inputs a transaction into t24, an override is raised in the transaction. Due to this a
record is created in DISPO.ITEMS application. The override s subject to FORCE dispo.
Until another user approves the DISPO.ITEMS record, the user is not allowed to authorise the
underlying transaction. Hence the other user sends a request to approve the dispo items record.
Once the dispo is approved, the underlying transaction does not pop up for force dispo. Because the
underlying transaction will be authorised by a workflow in T24.
Value Proposition:
With the introduction of force dispo, the T24 system waits for an external system to approve the
dispo items record.
Also, once the dispo is approved, the underlying transaction will not pop up for force dispo and it''ll
get authorised by the workflow in T24.
Replacement of DE.MT942.GENERATE phantom to service

Description:
The current DE.MT942.GENERATE phantom is replaced with a service to make it multi-threaded,

thereby improving the processing capability for auto generation of MT942 statements based on time
specified in the ACCOUNT.STATEMENT. But the method for raising adhoc 942 statements remains
the same.
Value Proposition:
Prior to R12, MT942 are produced on request either manually or on receipt of a Swift MT941
message by DE.MT942.GENERATE phantom. This is single threaded which means only 1 request can
be handled at a time and it also require manual intervention to enable and disable phantom.
In R12, this phantom is replaced with a Multi threaded services and fully automated based on the
frequency set in ACCOUNT.STATEMENT. Thus the process is made more efficient and fully
automated.
Multiple PV Management records

Description:
PV.MANAGEMENT has been enhanced to allow multiple records to be entered. This will enable
different classification and provisioning rules for different groups of products. For example
commercial loans may be treated differently to personal loans. The id to the PV.MANAGEMENT
table has been enhanced to allow values other than the previous default ID of “System”.
A category can only be specified in one PV.MANAGEMENT record.
Value Proposition:
Prior to R12, only one record is allowed in PV.MANAGEMENT, only allowing one classification and
provisioning rule to be applied to all the products.
From R12, Multiple records can be entered in PV.MANAGEMENT allowing Clients to define different
groups and products based on the requirements.
Option premiums denominated in any currency for FX OTC options

trades
Description:
Option premium/price for FX OTC Options can either be denominated in the contract currency or any
valid currency. To cater to this requirement new fields are added in DX.TRADE and DX.ORDER
applications. Premium defined in other currency is converted to the equivalent premium amount in
contract currency using the exchange rate which can be defined by the user.
Value Proposition:
Prior to R12, the premium can be denominated in contract currency only.
In R12, new option is introduced using which the Option premium/price can wither be denominated
in contract currency or any valid currency.
Swap Maturing on a Non-working Day

Description:
A new field MAT.PAYMENT.DATE is introduced in SWAP.PARAMETER table for the enhancement.
If the maturity date of a contract falls on a non-working day, the events scheduled for the contract
maturity will reflect the next working date as the value date (payment date).
This feature will be applicable only for the events at maturity, provided DAY.CONVENTION field is
defined as Following/ Modified Following and MAT.PAYMENT.DATE field in SWAP.PARAMETER is set
to Yes.
Take the example of a swap contract maturing on 15 August 2011 which happens to be a holiday.
With the field MAT.PAYMENT.DATE in SWAP.PARAMETER set to Yes and DAY.CONVENTION set to
Following, the value dates in accounting entries, delivery messages and balances files will be updated
as the next working day i.e. 16 August 2011 but the interest calculation will be done only up to the
maturity date i.e. 15 August 2011.
Value Proposition:
Prior t R12, All schedules falling on the maturity date, which happen to be a non-working day, then
the system, process the schedules on the non-working day even though DAY.CONVENTION is
specified as DAY.CONVENTION is not applied for events falling on swap maturity dates.
The new field MAT.PAYMENT.DATE is introduced in R12 to contol/decide the processing of schedules
falling under Non-Working day.
Image Management - Upload and Download documents from T24

Server
Description:
Image Management system now supports upload and download of documents from T24 Server
Value Proposition:
Prior to R12, Image Management works based on the file items stored & retrieved from the
local(Where webserver is running) systems
In R12, Image Management now support upload & download of file items from T24 Server
Advanced alerts in Asset Management

Description:
This development enables the clients and internal bank users to subscribe and unsubscribe for new
PWM alerts apart from the existing ones
The setup for the alerts can be done using the following tables. Records needs to be created in the
below mentioned tables for using alerts.
• EB.ALERT.TYPE
• TEC.ITEMS
• CUSTOMER
• DE.CUSTOMER.PREFERENCES
• EB.ALERT.REQUEST
Value Proposition:
In R12, new advanced alert options are introduced which can be enabled using simple set-ups. This
provides additional PWM alerts, which can be subscribed/unsubscribed by Client/Bank Users apart
from existing alerts.
Account Statement Service - Improved Handoff performance

Description:
A separate process of handing over the Handoff record and mapping process as a service runs
parallel during the COB job, reducing the time consumed for PRINT.ACCOUNT.STATEMENT job.
When PRINT.ACCOUNT.STMT determines that the message has to be processed via core delivery, it
writes the basic information required for the generation of hand-off record in a work file and
continues its process without waiting for delivery process. AC.STMT.SERVICE picks up records
updated in PRINT.ACCOUNT.STATEMENT job. The hand off records is built based on the read info and
application handoff to map and generate delivery reference is called. Delivery reference is updated in
the ACCOUNT.STATEMENT and processed record is deleted from work file.
Value Proposition:
Prior to R12, the process of handing over the Handoff and mapping are done within the COB job
PRINT.ACCOUNT.STATEMENT, which increased the overall COB timing.
Now this process is restructured and separate Service is introduced to attend Handoff & mapping
processes. As this service can be run in parallel to COB, this will reduce the time consumpton of job
PRINT.ACCOUNT.STATEMENT and overall COB execution time.
Replacement of NR phantoms with Service

Description:
The current Phantom mechanism has to be replaced with the Service, making it a multi-threaded
process, making it more efficient and to allow the functionality to continue to work on platforms
such as the Z-series and to ensure that the process can be scaled in a standard fashion.
Value Proposition:
In R11, the decoding and matching of Nostro related statement and ledger entries were being done
by the phantoms NR.DECODE and NR.AUTOMATCH. This process was single threaded and was
fraught with locking errors.
In R12, the problematic phantoms are replaced as efficient multi threaded services. This will reduce
the execution time and increases the server utilization effectively.
TJ - Enable/ Disable File/ Record Path Update in TRANSEND record

New Feature in R12 of JBASE
Description:
A new option is provided in jlogadmin command line utility to enable / disable the storage of record
and file path updates in the TRANSEND records. By default, these information are excluded from
recording in TRANSEND record. This option helps in reducing the disk space used by the TRANSEND
records in the logsets.
Value Proposition:
In R11, the TRANSEND record holds the details of the modified records, and the corresponding file
paths involved in any transaction. Storing these details leads to increase in size of the TRANSEND
records stored in TJ logset. These records can grow huge in a real time T24 implementation.
With the use of this new option in R12 jlogadmin command, the storage of records & file paths in
TRANSEND can be suppressed and this will reduce the diskspace of logsets considerably.
TJ - Compression of TJ log records

Description:
In R12, an option is provided in jlogadmin to compress/ decompress the TJ WRITE records which are
bigger in size. The records which are to be picked up for compression can be controlled by setting a
threshold size, and any WRITE record above this threshold size will be compressed. These
compressed TJ WRITE records helps in reducing the disk space. A decompression algorithm
reproduces the original data before replaying the records using jlogdup.
Value Proposition:
In R11, the TJ logging mechanism logs every jBASE WRITE to logset files without considering the size
of the data in WRITE records. So, when the WRITE records have huge data size , the logset size
increases proportionally prompting for frequent logfile switching.
From R12, the new switch -z can be used in jlogadmin to set the threshold, crossing which the TJ
WRITE will compress the record & write in logset. The decompression algorithm will reproduce
original data, whenever required. This can be easily switch on, off & easy to change the threshold
limit. This will be very much useful in reducing the diskspace of TJ logsets efficiently.
TJ - Network compression
Description:
In R12, new TJ network compression function is introduced to reduce the network transfer time of
the TJ logs. This will work in conjunction with TJ log record compression for records grated than
Threshold limit. Any TJ WRITES of size below the threshold set by the ‘jlodadmin -Z’ option are picked
up by the TJ Network compression function and compressed, before they are replayed to a remote
backup / hot standby server.
Value Proposition:
In R11, the TJ logging mechanism logs every jBASE WRITE to logset files without considering the size
of the data in WRITE records. And when these log sets are replayed to a backup server or a hot
standby server, they are transferred as huge uncompressed files over the network, which affects
performance.
In R12, the new TJ Network compression function works in conjunction with TJ record log
compression, which will compress records greater than TJ threshold limit defined. This Network
compression picks up the records below threshold limit & compress to reduce the diskspace size of TJ
logsets. This helps in the faster transfer of the TJ log files over the network.
jBASE Scalability
Description:
In R12, the OS Native/Advisory locking mechanism is changed into a POSIX based semaphore locking,
in order to handle the jBASE scalability issue. In this mechanism, when once a lock is identified as
group header lock, the detail of the lock is stored in a shared memory table.
By default, 1033 locks can be stored in the shared memory table, and it is configurable to the
maximum possible semaphores supported by the operating system.
This POSIX based locking mechanism can be activated or deactivated using the following
environment variable.
export JBASE_GROUP_LOCK=1
When this environment variable is not set, the default OS locking mechanism will be active.
Value Proposition:
Prior to TAFC R12, it has been noticed that jBase stops scaling vertically, even on a capable hardware.
When multiple agents try to access the same file, it ends up in creating huge Linked lists which
become a bottlenck for scalability.
In R12, new POSIX based semaphore locking mechanism is introduced to handle the jBase scalability
issue. This can be activated/deactivated simply by setting up the envieonment variable
"JBASE_GROUP_LOCK" in .profile. Hence, jBase is fully scalable now and hardware configurations will
be used efficiently.
Passbooks for Arrangements

New Feature in R12 of Retail Banking
Description:
A new field Passbook is introduced in Account Property Class, and if set to yes, passbook would be
printed for the particular AA account. It is valid for arrangement accounts with a Category code
defined in the SAVINGS record of ACCOUNT.CLASS application.
It is possible to change the value of the Passbook field from ‘Yes’ to ‘No’, and ‘No’ to ‘Yes’ for the
existing arrangement, through update Activity - ACCOUNTS-UPDATE- <account Property>. Both
cannot be done on the same day for the same account.
Value Proposition:
Prior to R12, there is no such feature to produce Passbook for Arrangement accounts.
In R12, a new functionality is introduced which will allow to print Passbook after checking the new
field Passbook in Account Property Class for the particular AA Acount.
Masking the Statement Entries

Description:
ENTRY.PRINT.MAS Field in AC.ALLOCATION.RULE is used to indicate if masking is required for an

Event Type.
When set to YES, masking is enabled for this Event Type and any accounting entries for this event
would be masked in statement printing/enquiry or passbook printing.
This is an associated multi valued field along with EVENT.TYPE field.
When raising accounting entries for this Event Type, if it is a STMT entry and if mask flag is set to YES,
then, system sets ‘YES’ in the MASK.PRINT field in STMT.ENTRY.
Value Proposition:
Prior to R12, there is no provision in Soft Accounting framework to mask entries from appearing in
account statements or during passbook printing.
In R12, new field ENTRY.PRINT.MAS in AC.ALLOCATION.RULE is introduced, which when set to ''Yes''
will enable masking for the Event type. The accounting entries for this event would be masked in
statement printing/enquiry or passbook printing.
New Interest Basis – E1 for LD

Description:
A new type of Interest Basis E1 (365/365) is introduced in INT.DAY.BASIS to support the Columbian
market for Treasury and Bonds Issuance through LD.
In this year basis, 365 days is used for interest days calculation, regardless of whether it is leap year
or not. February 29th is ignored in the calculation of days between dates for the purpose of
calculating interest days.
If Feb 29th is the start date, then it should be ignored and start date should be considered as Mar
1st.
If Feb 29th is the final date, then it is considered as a normal day and considered in the calculation
(as a standard calculation last day will be excluded).
The supported Interest Basis in LD is hardcoded in LD.FIELD.DEFINITIONS.
Value Proposition:
In R12, a new type of Interest Basis E1 (365/365) is introduced in INT.DAY.BASIS to support the
Columbian market for Treasury and Bonds Issuance through LD.
AA Core-Option for accounting waived charge amounts

Description:
A new option is introduced in ACCOUNTING property to raise separate accounting entries for
calculated charge and waived amount, such that it could be booked in separate profit and loss
category. This helps in maintaining the historical details of waiver offered to the customer for banks
analysis purpose. It also enables the bank to show the total charge amount and the waived amount
in the customer statements.
Value Proposition:
In Old release, Single accounting entry for net charge amount (Total charge – waived) alone is raised
for charge override.
In R13, Two separate accounting entries could be generated one for Total charge and another for
waived amount, so that a historical detail of waiver offered to the customer could be maintained.
AA Core-Pre-Notification for scheduled events

Enhancement in R13 of ARCHITECTURE & FRAMEWORK
Description:
Pre-notification advice is extended to all scheduled activities across the product line such as Lending,
Deposits, and Accounts.
Value Proposition:
Prior to R13 Pre-notification advice functionality was available only for cancellation event in AA
Deposits and Lending.
But now, in R13, Pre-Notification (Delivery Advice) is extended for all scheduled activities across
product lines such as Lending, Deposits, and Accounts (For example: Interest resets, Rollovers etc.).
AA Core-User Defined Periodic Attributes

Description:
Users could create additional Periodic Attribute Classes on their own apart from the ones released by
Temenos, more for local development.
Value Proposition:
In Earlier release users were not able to create additional periodic attribute classes locally based on
their requirement, as AA.PERIODIC.ATTRIBUTE.CLASS records are generally released by Temenos.
In R13, a new feature is introduced to enable clients to define additional

AA.PERIODIC.ATTRIBUTE.CLASS on their own apart from the ones released by Temenos. This
facilitates client specific rules to be defined locally and reduces dependency on core.
AA Core-Settlement to Internal Account

Description:
The new functionality allows the user to define an internal account as payin or payout account.
Value Proposition:
Earlier Customer account could alone be defined as payin or payout account in settlement property
conditions.
Now, from R13, Payin and Payout account fields of SETTLEMENT property now accepts an internal
account as well.
AA Core-Amortisation of credit charge

Description:
Amortisation is now enabled for rebates to realize PL from charge over a period.
Credit charges get reflected in cash flow reporting for EIR calculations.
Value Proposition:
Prior to R13 Amortisation was not available for rebates (credit charges). It was available only for due
charges.
From R13, Amortisation is available for rebates to realize PL from charge over a period. Additionally,
credit charges also get reflected in cash flow reporting for EIR calculations.
AA Core-Usability Improvements
Description:
This functionality improves user''s experience with Model bank.
Value Proposition:
In Older release composite screen design did not include some usability features which are now
improved in the current model bank.
The composite screen design is enhanced in the Retail Model Bank for the following:
1) Single Customer view is refined with additional feature to include new enquiries for displaying the
Customer Products.
2) In Commitment savings plan, the product conditions are modified with added functionality and
properties are restructured within the Parent and the child Product.
3) In Deposit overview, a single click to Pre-close is enabled
4) Composite screen and the tabbed screens in various role based home pages are redesigned to
have a better look and feel.
AA - Lending-Automated Scheduled Disbursements

Description:
Users could automate the Scheduling and Processing of Full or Partial Disbursements and
automatically settle the Scheduled Disbursements through settlement instructions and
PAYOUT.RULES definition.
To support this, PAYOUT.RULES property class is enabled in lending product line.A new balance
AVL<ACCOUNT> is created exclusively for scheduled disbursement. It indicates the loan amount
available for disbursement. This is a contingent credit balance on the loan which is credited when the
disbursement bill is made payable.
Value Proposition:
In Lower Release AA, Automatic disbursement is not possible. It has to be initiated separately by
transaction activity through FT, Teller etc.
In R13 Disbursements could now be automated through payment schedule definition and customer
account could be credited using PAYOUT.RULES definition.
AA - Lending-Rebates for AA lending

Description:
1) Rebate (Credit charge) is extended for Lending product line.
2) PAYOUT.RULES Property Class is available in the Lending product line which enables rebate
(payable charge) to be paid out to the customer, if required.
Value Proposition:
In Earlier release Rebate processing was not possible in AA Lending Product Line.
Now in R13 Rebate is extended for Lending products and could be paid out to the customer by using
PAYOUT.RULES property, which is now enabled for Lending.
AA - Lending-Amortisation of credit charge

Description:
1)Amortisation is now enabled for rebates to realize PL from charge over a period.
2)Credit charges get reflected in cash flow reporting for EIR calculations.
Value Proposition:
Prior to R13 Amortisation was not available for rebates (credit charges). It was available only for due
charges.
In R13 Amortisation is available for rebates to realize PL from charge over a period. Additionally,
credit charges also get reflected in cash flow reporting for EIR calculations.
AA - Lending-Penalty interest included as part of outstanding bills

Description:
Penalty interest gets accrued based on the overdue balance defined and gets stored in
ACCPENALTYINT balance as a single accrual amount, not as part of each outstanding bill. Therefore,
when a customer makes a repayment, Penalty interest could not be repaid per bill.
Value Proposition:
In Earlier releases Penalty interest gets accrued based on the overdue balance defined and gets
stored in ACCPENALTYINT balance as a single accrual amount, not as part of each outstanding bill.
Therefore, when a customer makes a repayment, Penalty interest could not be repaid per bill.
Now in R13 penalty interest could be stored as part of each outstanding bill, such that settlement
and adjustment of penalty happens per bill.
BizTalk Adapter - Service Connectivity

Description:
This improvement provides a web service layer between the developer and T24 which eases the
connectivity configuration for the developer.
Value Proposition:
Prior to R13, T24 BizTalk adapter service connectivity values were not available.
BizTalk Adapter is updated to make use of Component Framework based connectivity.To support the
BizTalk Adapter, the Installation flow is Modified.
Fiorano Adapter - T24 Inbound & Outbound Adapter

Description:
Fiorano Adapters provide robust application integration capability based on the peer-to-peer
architecture.
Value Proposition:
Prior to R13, adapters were available only for .Net Framework, and no equivalent, optimised
middleware solution were avaialble for the Java-based Enterprise Stacks, .
From R13, Fiorano Adapters are introduced for Java-based Enterprise Stacks to integrate T24 and
external system across an Enterprise Service Grid.It can support inbound and outbound messaging
capabilities at runtime along with T24 meta-data discovery capability at design time.
Component Service as an Exit Point

Description:
Multiple fields in the flow designer are selected using Shift+ click or Ctrl+click keys and added using
Add button. Add All button is also used to select and add all the fields to the flow. The display name
for the fields added to the flow are editable.
Move up and Move Down buttons are used to change the displaying order of the selected fields.
Remove button is used to remove any of the added fields from the flow.
Value Proposition:
Prior to R13, the Integration Events were linked either to Version or to Application.
In R13, The Component Service option is included under Exit Point Detail, which in turn enables the
Component Service Details to define event for T24 Components which will provide below benefits
1) The definition of events is allowed for Component Service operation in Event Designer.
2) The usability of the Event Designer is improved and it is now possible to add custom fields which
could be used later for filtering the eents.
TSA Service as an Exit Point

Description:
A new Exit Point of type TSA Service is added to provide this functionality. It allows the user to define
event for TSA Service and to trigger an event during the execution of COB or a Service.
Value Proposition:
In old releases, the Integration Events were linked either to Version or to Application and no options
were provided for User to define event to trigger TSA Services.
From R13,
1) User can define event for TSA Service and can trigger an event during the execution of COB or a
service.
2) User can add a field from the related applications to the flow.
Join Fields
Description:
Now it is possible to add custom fields to the Flow. This facilitates filtering of the event based on the
custom field value.
Value Proposition:
In R13, users can add a field from the related applications to the flow.
Custom Fields
Description:
Now it is possible to add custom fields to the Flow. This facilitates filtering of the event based on the
custom field value.
Value Proposition:
This enhancement provides filtering of the event based on the custom field value.
Customised Field Name

Description:
The field name in the event XML Data can be a meaningful name specified by the user. This is
achieved by editing the Schema Name field in the flow definition.
Value Proposition:
In R13, the users can now be able to provide a meaningful name for the field name in the event of a
XML Data.
Customised Schema root element name

Description:
The flow schema root element name is the name of the flow. This provides an option to the user to
decide the root element name.
Value Proposition:
In R13, this provides an option to the user to decide the root element name.
IntegrationStudio EE-Usability of Flow Designer

Description:
The flow designer is now enhanced based on Customer Feedback. It is now possible to rearrange the
fields in the Flow Enrichment section in the Flow Designer. Also there is an option to select multiple
fields and add it to the flow. The “Add All” button in the Flow Designer allows the user to add all the
fields to the flow.
Value Proposition:
In R13, the users can rearrange the fields in the Flow Enrichment section in the Flow Designer.Also,
they can select multiple fields and add it to the flow or with "Add All" button users can add all the
fields to the flow.
Integration Studio(.NET) & TWS(.NET)- Service Connectivity

Description:
The IF .NET Event Designer is updated to make use of Component Framework based connectivity.
Additionally, the Service Connectivity option is now enabled to IF .NET Event Designer project.
To cater this functional requirements, the Service Connectivity option is enabled to IF .NET Event
Designer project.
Value Proposition:
The R13 improvements provides a web service layer between the developer and T24 which will ease
manageability of the connectivity configuration.
Integration Studio(.NET) - Component Service as an Exit Point

Description:
1) The definition of events is allowed for Component Service in Event Designer.
2) The schema name (display name) for the fields added to the flow are editable so as to provide
meaningful schema names.
Value Proposition:
Prior to R13, the Integration Events were linked either to Version or to Application and the Event
Designer displayed default schema name for the fields added to the flow.
From R13, The Event Designer is modified which will provide the following features
1) Linking Integration Events to Component Service option
2) Editable schema name for the fields added to the flow
Integration Studio(.NET)- Customised Field Name

Description:
The field name in the event XML Data can be a customised, meaningful name specified by the user.
This is achieved by editing the Schema Name field in the flow definition.
Value Proposition:
In R13, the users can now be able to provide a meaningful name for the field name in the event of a
XML Data.
TOCF (EE) to support bulk initial load capability

Description:
TOCF (EE) component is updated so that the JMS message holds additional data . This contains a
parameter value, which could be used by external system to do further processing of messages.
Value Proposition:
From R13, TOCF(EE) supports bulk initial load capacity to helps processing of messages based on this
property values and at present, Integration Framework uses this functionality to deliver the events
based on these property values.
TOCFEE - Support for OFSML 1.4.0

Description:
The major improvement in OFSML 1.4 is the provision of enhanced support for AA and bulk
transactions.
Value Proposition:
In prior releases support for bulk transaction and AA contract creation was not available in OFSML
1.3.
From R13, OFSML 1.4.0 supports bulk transactions.
TOCFEE - Enhanced exception handling

Description:
To cater the functional requirement, the exception T24InternalException is added in TOCF(EE). This
exception is displayed if T24 fatal error condition occurs. With this enhancement, the TOCF(EE) can
capture tafc_agent layer messages, if the property ''incCapOutIfError'' is set to one of the following
values:
1) True
2) Yes
3) 1
Value Proposition:
Previously, the TAFC agent message cannot be captured.

From R13, with the new type of exception added to TOCF (EE), the TAFC agent messages can be
captured in the application server-side. Additionally, the error handling process is improved on
TOCF_EE layer in case of FATAL_ERROR occurrence on server (T24).
TOCFEE - MESSAGETTL property

Description:
A new property named MESSAGETTL is introduced in adapter configuration section of tcserver.xml.

This property is used to define the time limit for queued messages.
Value Proposition:
Prior to R13, the unprocessed messaged will remain in queue without any certain time limit.
From R13, the time limit for messages can be customised either to discard or process the message
within certain time limit.
TOCF.NET - OFS Connector support

Description:
TOCF.NET is modified to use OFS Connector to connect to T24.
Value Proposition:
R13 provides an alternative method to connect to T24.
From R13, service connector configuration is now modified to configure OFS connector based
connectivity
Integration Studio(.NET), TWS - Common Login Screen

Description:
All the available modes of T24 connectivity and steps involved in it are merged into a single-window
''Integration Studio Defaults'' dialog box.
Value Proposition:
Prior to R13, connecting to T24 required multiple steps with separate dialog boxes for each steps.
Previously, to change a connection property/link, user must modify it in the installation files.
In R13, The standardised logon screen is available for all the .NET components and the logon process
is simplified for users.
Technology - Application Performance Monitoring

Description:
This will provide an “out of the box” application performance monitoring solution for the model bank
product
It may be deployed within our partners monitoring products, i.e. Microsoft, IBM, or Oracle, with
minimal setup and configuration change
Value Proposition:
T24 previously used a custom built monitoring solution called T24 Monitor.
Now from R13 a new operational performance monitoring tool called tOP (t24 Operational
Performance monitoring) has been developed. This tool has been developed based on the splunk
platform.It serves as an integrated T24 enterprise monitoring solution.
History of Deleted T24 Items

Description:
A new file suffix $DEL is introduced to store all the deleted transaction details. An unauthorized
transaction that undergoes deletion activity
will now be stored in the database for audit trail.
Value Proposition:
Prior to R13, When unauthorized transactions are deleted, they are permanently removed from the
database. There is no audit trail for the deleted unauthorized records
From R13, With the introduction of $DEL file, any unauthorized transaction deleted by the user will
be preserved in the database and used for audit trail.
Customisation of Mandatory Selection Field in Enquiries

Description:
New field to specify N number of selection fields viz, NO.MANDATORY.SELECTION, is introduced to

work in conjunction with SELECTION.FLDS in Enquiry application.
Value Proposition:
Prior to R13, Mandatory selection criteria for an enquiry are frozen at design time. SELECTION.FIELDS
and REQUIRED.SEL fields are defined in the Enquiry and user is forced to provide values to these
selection fields before executing the enquiry.
In R13,With the inclusion of new customisation option , runtime flexibility is given to an end user to
pick selection criteria fields for mandatory input while launching an enquiry.
Implementation of User Roles

Description:
The concept of user roles (EB.USER.ROLES) is introduced and the functionality is below
EB.USER.ROLES is a new application in which all the relevant application restrictions for the Roles are
defined.
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.
A user can switch roles using a utility defined under TOOLS menu in Browser.
Value Proposition:
In R13, 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.
Browser Enhancements - Tear-Off

Description:
An option called tear off is included in all enquiry response which is built inside a composite screen.
On clicking the tear off option, the enquiry response will be viewed in a new window offering clear
view.
Tear off option can be avoided for the enquiry of a particular frame by defining NO.TEAROFF
attribute for that frame in EB.COMPOSITE.SCREEN
Value Proposition:
In Old browsers, The enquiries responses were displayed on the same composite screen within the
space provided with horizontal and vertical scroll bars. A clear view of the enquiry response was not
provided when its size is greater than the space provided.
In R13, The user is provided with a clear view of enquiry response in a new window from the parent
composite screen or tabbed window in Browser.
Browser Toolbars enhancements

Description:
New fields ORIENTATION and STYLE are added in BROWSER.TOOLBAR for Browser and ARC IB.
The field ORIENTATION is used to change the display orientation of the tool bar either horizontally or
vertically. The field STYLE is linked to EB.ATTRIBUTES which contains predefined classes in a
Cascading Style Sheet (CSS).
Value Proposition:
Prior to R13, Browser provides only horizontal orientation and no styling and highlighting options for
the browser tool bar.
In R13, Users are allowed to change the display orientation of browser toolbar to vertical or
horizontal and provide styling and highlighting options for the toolbar.
Customised message is displayed on deletion.
Browser - Drop-down Enquiry Selection tool

Description:
All the fields with the drop-down enquiry support the selection tool. User could set the selection
criteria and restrict the results on a drop-down enquiry.
Value Proposition:
Prior to R13, The selection tool was not available for all drop-down enquiries and it need to be set
only at version level. Users were not able to enter selection criteria
In R13, Users are able to specify the selection criteria to search and restrict the results of drop down
enquiries.
Payments - Straight Through Processing

Description:
From R13 new product VS - Straight Through Processing is introduced to process SWIFT messages.
STP integrates with Integration Framework to send and receive SWIFT messages to external STP
processing software.
Value Proposition:
Straight Through Processing product - VS, integrates with Integration framework for SWIFT messages
to be enhanced by an external STP processing software. This reduces the time of settlement and
transaction costs for the Bank.
Swift as an optional module

Description:
SWIFT messages will get formatted only if SF product is installed, else the messages will go to
“Repair” in both the directions.
Value Proposition:
No such functionality available earlier. If DE product was installed, client had access to all the carrier
modules like SWIFT, PRINT, XML, SMS, SECUREMSG, ETC.
In R13, new product ‘SF’ is introduced for SWIFT.SWIFT messages will get formatted only if SF
product is installed, else the messages will go to “Repair” in both the directions
Treasury - SWIFT Changes

Description:
1) Ability to include the type, date and version of the Agreement and Year of Definition respectively
in the MT300 messages.
2) Ability to validate and avert the usage of unit value of gold in GOZ and TOZ in the MT600 series.
Validation on FX template yields this result.
Value Proposition:
In older release optional tags 77H and 14C for MT300 messages were not supported.
The MT600 series (MT600, MT604 and MT605) allows the values ‘GOZ or TOZ’ as quantity of metals
where deals involve GOLD.
From R13 MT 300, the optional tags 77H and 14C are included to capture the type, date and version
of the Agreement and Year of Definition respectively. For MT 600 series messages (600,604,605),
when GOLD is involved as the metal type of transaction, the quantity does not measure in “GOZ or
TOZ” unit values.
FATCA - Foreign Account Tax Compliance Act

Description:
A new module FATCA (FA) is introduced. This has been initially developed to meet customer
requirements on the customer categorisation phase for FATCA.
Value Proposition:
From R13, the new module - FA(FATCA) is introduced to assist clients in becoming compliant with
customer categorisation phase of FATCA Law.
Ability to define an Asset Type to be excluded from the T24 Balance

Description:
The field BAL.TO.EXLD in IFRS.ACCT.METHODS can be used to define the Balance / Asset types to be
excluded from T24 balances. This functionality is available only for AC.BALANCE.TYPE records with
REPORTING.TYPE set to VIRTUAL.
Value Proposition:
Prior to R13,the option to exclude specific Asset type from T24 Balance was not avaible in T24.
In R13, the clients will be able to specify Balance/Asset Types that need not be reckoned for arriving
at T24 balances for IFRS related calculation purposes.
Ability to handle the expected life of an AA lending contract

Description:
The application IFRS.SUB.TYPE has been enhanced to except the value of "Expected" in the field
"Term". The processing for an IFRS.SUB.TYPE defined as expected is similar to that of one defined as
"Short", however the difference between the two is that once the date of the expected life is
reached the contract will no longer be subject to IFRS processing.
Value Proposition:
From R13, the banks will be able to calculate the cash flows for AA using an expected life.
Allow the creation of Group Limit

Description:
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.
Value Proposition:
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.
Reducing and Non Reducing limits in a Limit Hierarchy

Description:
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.Although,there is a
limitation on this functionality, that a Revolving Limit cannot be defined under a Non Revolving Limit
Parent.
Value Proposition:
In R13, The repaid portion of a Non Revolving Limit can be utilised by other Limits in the group,
subject to availability of overall Limit.
Intercompany Accounting
Description:
A new multi valued set of fields have been introduced to allow the routing company to be defined at
lead company level:
LEAD.COMPANY - this field is used to specify the lead company
ROUTING.COMPANY - This field is used to define the routing company in the structure.
When left blank the field will be defaulted with the LEAD.COMPANY id
This field will accept either the lead company id or a branch belonging to the defined
LEAD.COMPANY
ROUTING.MNEMONIC - no input field, system will default the value based on the
ROUTING.COMPANY
Value Proposition:
Prior to R13, it was not possible to restrict inter company accounting to branches with the same lead
company
From R13, With the introduction of the field Routing Company, a bank can maintain one account for
each currency for each Branch only at HO level or through the Designated Company level. Thereby if
there are 100 branches and 5 currencies involved, there will be only 500 accounts opened at the HO
books and each Branch under the Lead Company will have only 5 inter branch accounts of HO
Accounts
Customer Relationship -Personal Entity

Description:
Three new applications have been released, PERSON.ENTITY, CUSTOMER.REL.GROUP and

CUSTOMER.RELATIONSHIP to record details of individuals or entities that are not customers of the
bank and to map the various relationships between T24 customers and non customers.
CUSTOMER.REL.GROUP is used to store details of the customer relation group at the highest level.
Value Proposition:
Prior to R13, T24 can only allow
1) creation of prospect record, but they will be purged every 180 days.
2) functionality to state relationships between 2 existing t24 customers
From R13, Banks will have the
1) Ability to log the details of individuals who are not their customers but who have a relationship
with a customer.
2) Potential to use the new functionality for prospect management, if the bank wants to keep
prospects and clients separate
Increase in the ID of ACCT.GEN.CONDITION from 4 to 6 characters

Description:
The length of the id of ACCT.GEN.CONDITION has been increased to 6 characters. The increase in id
length will enable the client to define new customer groups and create new products aimed at
different customer groups. Along with ACCT.GEN.CONDITION, the id length / length of fields holding
the group id have also been changed to 6 characters.
Value Proposition:
Prior to R13, The length of ACCT.GEN.CONDITION is restricted to 4 charecters.
In R13, The increase in id length to 6 characters will enable the client to define new customer groups
and create new products aimed at different customer groups.
Field POS.EXP.DATE in STMT.ENTRY for Position Accounting entries

Description:
The field POS.EXP.DATE is introduced in STMT.ENTRY and STMT.ENT.DETAIL records to record the
actual exposure date for position account entries.
Value Proposition:
Prior to R13, The position entries raised by core accounting do not maintain any separate
information in the STMT.ENTRY with regards to date of position exposure. The field VALUE.DATE
used to be considered the exposure date, but in reality, this field does not reflect the actual exposure
date and individual applications need to be queried forgetting position exposure information.
In R13, this new functionality will enable the exposure date for position accounting entries to be
recorded in the STMT.ENTRY or STMT.ENTRY.DETAIL records. This will provide the Bank’s with a
facility to query on the actual exposure dates updated here, instead of querying individual
applications.
Provisioning Module to support Accounts (AC& AR)

Description:
The application PV.MANAGEMENT will now allow additional modules AC(Accounts) and AR(Retail
Accounts)
Value Proposition:
Prior to R13, the Provisioning module was not able to handle Overdraft Accounts in both the AC and
AR modules.
In R13, this functionality will allow clients to classify, calculate, manually adjust and post provisioning
amounts on accounts which are in overdraft.
Provision Asset Classification Frequency
Description:
A new field CLASS.FREQUENCY has been added to the PV.MANAGEMENT application.
Value Proposition:
Prior to R13 ,only one frequency can be set using JOB.FREQUENCY field for all activities.
In R13, with the introduction of new fields, Clients will be able to set a different frequency for the
classification process, for example the classification on a daily basis, but the calculation and posting
on a monthly basis.
Changes to EB.ACCRUAL to allow multiple amortisation options

Description:
Allow multiple amortisation options through EB.ACCRUAL.The EB.ACCRUAL mechanism has been
modified to handle a new frequency ‘E’ for the up front fees collected from the customer.
Value Proposition:
Prior to R13, the only amortisation method handled in T24 is the Straight Line Method.
From R13, Fees collected up front on a loan contract can undergo different types of amortisation
treatments, for example Straight line amortisation ,No amortisation ,Deferred amortisation.
Transaction Recycler
Description:
A new module Transaction Recycler has been released.The module components are
RC.PRIORITY,RC.PRODUCT.PRIORITY,RC.TYPE,RC.CAPTURE,RC.CONDITION,RC.CONTRACT.PRIORITY.Th
ese parameter tables can be configured to capture specific types of transaction by product.The
captured transactions are written to the RC.DETAIL application, where the system uses the rules
created so that it will then be able to keep reprocessing these transactions until they are either
completed or abandoned.
Value Proposition:
Prior to R13, there is no automated solution to capture transactions which could not be completed.
From R13, client will be able to create pre defined sets of rules which will capture transactions, so
that they are automatically retried at pre determined intervals for a pre defined period of time.
Multiple Posting restrictions in Customer and Account

Description:
During account closure, multiple posting restrictions are configured for the account level posting
restrictions in the table ACCOUNT.PARAMETER and system will act accordingly.The field
POSTING.RESTRICT in ACCOUNT.PARAMETER has options as Single and Multiple / None.
Value Proposition:
Prior to R12, T24 supports only one posting restriction at a time and when a bank wants to apply
another posting restriction, system will overwrite the existing value.
In R13, this new functionality will allow the setup of a variety of Posting restrictions at Customer
and/or Account level. The end approver can take an informed decision based on these Posting
Restrictions.
Retain Account balance in Account - For upgrade clients

Description:
The field RETAIN.AC.BALANCES has been introduced in ACCOUNT.PARAMETER and this is available
for input only at the time of upgrade. It accepts a value of NULL or YES or NO. For clients upgrading
from lower releases to R12 release, the account balances could be maintained in ACCOUNT as well,
in addition to EB.CONTRACT.BALANCES record based on the value set to this field.
Value Proposition:
From R12 release, the balance fields were moved from Account to EB.CONTRACT.BALANCE record.
In R13, new option is introduced to maintain the Account balances in ACCOUNT. Now with this ability
to maintain the balances at ACCOUNT as well as EB.CONTRACT.BALANCES, the existing VERSIONS /
routines will still be able to use the various balance related fields maintained at the ACCOUNT level
obviating the need to redo everything.
Account Closure - Pre close simulation

Description:
The application AC.PRE.CLOSURE.DETAILS can be used to run a simulation which will return all the
calculated settlement amounts and a list of any error or override messages that would prevent an
actual closure from taking place.
Value Proposition:
Prior to R13, there is no functionality to provide a complete list of actions on an account before it can
be closed.
In R13, with the introduction of R13, Banks can now the new application AC.PRE.CLOSURE.DETAILS to
simulate the account closure for AC accounts, the system will return the calculated balances and any
actions that need to be done on the account in order to close it.
F Entries in OFS Clearing

Description:
T24 OFS.CLEARING will accept incoming transactions with the value date greater than the current
date. Two new fields FWD.ENTRIES and DELETE.FWDS have been added to AC.ENTRY.PARAM to
allow the generation and removal of “F” type forward entries.
Value Proposition:
Prior to R13, T24 OFS.CLEARING does not accept incoming transactions with value date greater than
the current date.
In R13,the transactions with a value date greater than the current date will be raised as Forward
dated “F” entries in the system. These entries will update available balance ladder in the respective
EB.CONTRACT.BALANCES record of the ACCOUNT, depending on the setup in the
ACCOUNT.PARAMETER.
Change Exposure ladder for Accounts

Description:
The application AC.REBUILD.EXPOSURE is introduced to make the adjustments relating to the

exposure dates and amounts.The following two mechanisms are offered to make the exposure date
adjustments:
• Redefine the exposure ladder
• Adjust the dates
Value Proposition:
Prior to R13, T24 ACCOUNT/ECB balance fields get updated irrespective of actual exposure dates.
In R13, with the introduction of this new functionality, Bank can make adjustments relating to the
exposure dates and amounts for accounts. For example, alter the EXPOSURE.DATE to provide funds
for a select Customer of the Bank, whose Cheque sent for collection has still not been realized.
Internet Banking Enhancement - Temenos Connect Internet Banking -

Retail and Corporate
Description:
The significant of TCIB is that it now incorporates a product-based platform solution for the
presentation layer rather than a customer development programming framework .
he Internet Banking presentation layer is now built using the edgeConnect IDE and the presentation
layer can be modified without touching the code.
Value Proposition:
From R14 , Banks can modify the presentation layer to suit their Internet banking requirements
without much focus on code development
Mobile Banking Enhancement - Customizable CSS for XHTML Channel

during Installation
Description:
The Customize Browser CSS option is introduced in both the payment and the banking installers to
incorporate the customized CSS files
Value Proposition:
Prior to R14 , To customize the CSS, jsp files in the payment.war and banking.war were edited
From R14 , The Customize Browser CSS option is introduced in both the payment and the banking
installers to incorporate the customized CSS files.
Mobile Banking Enhancement - Customizable CSS for XHTML Channel

during Installation
Description:
The new cloud-based Image management feature is supported through the Microsoft Windows
Azure™ environment. The uploaded files are stored in the cloud-storage and are available to the end
user through hyperlinks in T24 Browser.
Cloud-storage accepts all types of files; however, T24 Browser directly displays the images and opens
other file types using an associated application. In this way, various file types such as Images, audio
files, video files, Acrobat PDF, Word documents, spread sheets can be made available to the user
through cloud-storage.
Value Proposition:
Prior to R14 , Image management process involved writing and reading files from the local or
network file systems. From R14 , Image management feature is supported through the Microsoft
Windows Azure™ environment and the uploaded files are stored in the cloud-storage and are
available to the end user through hyperlinks in T24 Browser
Database - Data Encryption

Description:
T24 data is stored in the encrypted form so that only authorised access can decrypt and access the
data.
• Base key
As a first level of security a base key is provided for all the tables. Protection of the base encryption
keys are applied such that tampering, removal or cloning of the key records disabled the key
effectively.
• ENCRYPT qualifier
ENCRYPT qualifier is provided along with the CREATE-FILE utility. The stub/VOC holds the encryption
key provided in encrypted form.
• Encryption functionality is provided for all XML, BLOB and Promoted Columns.
• The encryption facility is not provided for the Real Columns.
• Translation of JQL to SQL is suppressed.
• JEDI_XMLDRIVER_ENCRYPT_ALL environment variable is used to encrypt all the files created

thereafter.
Value Proposition:
Data encryption and decryption provides a high security for the data. The driver provided encryption
functionality comes as an extra security along with encryption functionality provided by the
relational database.
Multi time zone

Description:
A new facility to define and store all time based information in the local time zone is introduced
Value Proposition:
Prior to R14, All customer transactions and user based setups were done based on the application
server time.
From R14, T24 supports multiple countries and its time zones in single instance. It provides local time
of the actual branch from where the transaction originates and facilitates the representation of local
time zones throughout the T24 application in the format DATE:HOURS:MINUTES:SECONDS
US Date format
Description:
New option to display the date in MM/DD/YYYY format is supported. This new option is introduced
for the DATE.FORMAT fields both in LANGUAGE and USER tables.
Value Proposition:
The US Date format - MM/DD/YYYY was not available before and this format is included now as part
of R14.
This new option is introduced for the DATE.FORMAT fields both in LANGUAGE and USER tables.
Logging Static Data Changes

Description:
New enhancement made in PROTOCOL table to track the changes for the transaction. A static change
report is generated on EOD with the existing logging details and the Curr.No details.
Value Proposition:
In R14, the new field TXN.COMMIT.LOG is introduced in USER application. This will enable logging
static data changes in PROTOCOL and update CURR.NO details. Based on the details recorded in
PROTOCOL file, the static change report is generated to compare the current Curr.no record with the
previous Curr.no record details.
Data Lifecycle Management

Description:
A new archival mechanism is introduced to move historical data to a separate database rather than
moving it to another table in existing database. The new database conveniently called “RO” is
introduced to store the archival data.
Value Proposition:
Prior to R14, Archiving is used to archive historical data to $ARC files but the $ARC files were
maintained in same live database which increased the load on live database.
In R14, the archiving is enhanced to move historic data of $ARC table from live to RO database.
The “RO” database is used as a multi-dimensional model for easier reporting. It provides column
storage and indexes for much faster reporting.
ARC IB - Transaction confirmation using Challenge Response

Description:
Different transaction authentication methods configured for same External User record
Value Proposition:
Prior to R14, ARC IB provides transaction verification methods while committing and authorising the
transactions.Howvere, they are hard to use and did not render enough protection against MiMT
(Man in Middle attack).
In R14, New solutions are designed to overcome the current ARC IB limitations using below ways
1) Different transaction authentication methods configured for same External User record.
2) Existing Challenge Response method is enhanced to get the “challenge” value from either external
authentication server or from pre-configured field defined at the transaction level.
Joint Holder Structure - Tax provisioning

Description:
New feature to split the tax calculated on an income for a primary customer amongst the primary
and joint customers in a pre-defined percentage.
Value Proposition:
Prior to R14, there was no provision to split the income and tax amounts between primary and join
customers.
In R14, the CUSTOMER.RELATIONSHIP model is enhanced to provide the new functionaly to calculate
the tax splits between the various joint holders based on the tax types linked to them.
Incorporating International Holidays in Market Rates

Description:
New enhancement to allow T24 to meet the regional market requirement for handling FX market
rest dates
Value Proposition:
From R14, new application ST.RATE.PARAMETER is introduced to provide the required base country
and to combine holiday definition to refer and decide the rest dates in FORWARD.RATES and
PERIODIC.INTEREST applications. Post set-up of the new table, the system ignores the base (local)
currency-country that has been defined in the company record.
This functionality was not available in previous releases.
Columbian Interest Basis ''A4''

Description:
New Interest Basis ''A4'' is introduced to handle the additional requirements in South American
market.
Value Proposition:
Prior to R14, T24 only supports 30/360 interest basis for calculating the number of days between a
given two dates using ‘A2’ and ‘A3’ interest basis.
From R14, a new interest day basis ''A4'' is being introduced to cater to South American market’s
interest calculation. The expectation on the new interest basis ''A4'' is that when there is a flow
starting from month end and ending in another month end (interest period start and end dates are
month ends), then, it should be considered as 30 day period. The month end dates differ based on
whether it is leap year or not.
Inter-Company Accounting Enhancements - Tax and PL in Customer

Company
Description:
T24 is enhanced to allow the P&L and Tax accounting entries to be booked in the company of the
customer for the applications Funds Transfer, Securities and Derivatives.
Value Proposition:
Prior to R14, Standard T24 functionality is to book all tax and P&L entries in the company where the
transaction is processed
In R14, it is possible to book the accounting for Tax and P&L entries in the company of a customer
account as opposed to the company the transaction is booked in, for the applications Funds Transfer,
Securities and Derivatives.
Multi Company Enhancement - Local Nostros

Description:
New changes to allow Nostro accounts to be created in other companies and to maintain their own
local Nostro accounts for local transactions
Value Proposition:
Prior to R14, In a multi company set up, the system does not allow the creation of Nostro accounts in
companies except in the lead company
In R14, the restriction in the system to create local Nostro accounts in the underlying companies is
removed. This allows Nostro account records to be created in the company records in addition to the
Nostro Company.
Recycler Enhancements - Transanction cycler

Description:
Additional features are enabled in Recycler
Value Proposition:
In R14, below additional features are enabled in Recycler
•Recycler is configured as an Online retry service to activate pending transactions against a

settlement whenever certain events like Credit to the account, Removal of posting restriction or
Unblocking of locked funds from the account takes place.
•Ability to cancel or terminate a pending Recycler transaction, if required.
•Facility to capture a fund blocked on an account into Recycler and subsequently retry with core
cycler framework using cycler priority settings.
•For certain transactions which are captured by Recycler for retry, have facility to block funds for the
transaction amount in the settlement account and map it against the recycler transaction.
• Ability to partially settle a captured transaction within cycler framework.
Account Enhancement - HVT parameterization

Description:
HVT Parameterization
Value Proposition:
Previously, the core table AC.AUTO.ACCOUNT is used to configure SYSTEM.IDs and

TRANSACTION.CODE''s that are to be excluded from hitting the sub accounts
From R14, new enhancement added to control the HVT parameterization to control HVT conversion
company level & Category level
1.HVT parameterization can be set at company level or system level or both a company level and
system level. For each lead company a different parameter table can be defined.
2.Accounts with multiple categories can be defined for HVT processing at company level. Option has
provided either to exclude or include a defined range of category of accounts for HVT default
processing.
3.Increase in system performance: Transactions for the HVT accounts will not update the account
balances and its related tables directly. It will be recorded in AC.HVT.TRIGGER (live file which holds
the transaction details of the HVT accounts before merging) and later merged with the
corresponding account’s main record by the running the service behind within the defined
HVT.MERGE.INTERVAL time.
Enhancements for ISO20022 XML Account Statement

Description:
CAMT Statement generation
Value Proposition:
In R14, With the introduction of new CAMT XML statements the organizations can comply with the
new regulation of the regulator.
The camt solution has been packaged into the T24 ISO20022 XML Account Statement Module (‘IX’ -
ISO20022 Statement). The product “IX” must be installed to use the Camt statement functionality.
Enterprise Framework- Integration Framework Enhancements

Description:
Improvements to integration flow schema to provide a robust message definition from T24
Value Proposition:
Prior to R14,
1. Integration Framework did not recognized the association between the fields.
2. Integration Framework handled only data of type “String” but majority of the component service
operation parameters were of complex type data structures and other simple types such as Integer
and Boolean.
In R14,
1. Information on association between T24 fields
With this improvement the schema provides information on association of fields as defined in T24
where multiple fields are associated together to form a group.
2. Schema for complex type component service parameter
With this improvement, it is now possible to use complex type parameters of component services in
integration flows with each parameter being defined in a schema document which is then a part of
the master schema that represents the integration flow. Also, the other unsupported simple types
such as Integer and Boolean are also supported.
Enterprise Framework- Platform Framework Enhancements

Description:
Additional functionality in Platform Framework to add the filter called DF_FILTER.Data Filter captures
all the configured data events and stores in a single file.This file can used for the reporting purposes
Value Proposition:
In R14,
The filter called DF_FILTER can be configured to filter the data being updated in a transaction.
1.DF_FILTER record is configured in F.SCHEMA file
2.This record contains the names of the file that has to be filtered
3.Either the whole record or just the record id can be filtered.
4.The filtered record is stored in a new file F.DATA.EVENTS.
5.Each data event is captured with a unique record id.
6.Captured records can be customized with application id and transaction id for further references.
Islamic Banking -Enhancement in Istisna and Parallel Istisna Finance

Description:
In Istisna and Parallel Istisna finance, the bank enters into a parallel contract with third party to have
the subject commodity / asset manufactured or built or assembled.
Value Proposition:
The following functions were supported in the Istisna Retail and Corporate finance :
• Capturing asset details
• Making supplier payments for manufacturing the asset
• Asset purchase and sale
In Istisna and Parallel Istisna finance the functions are added:
• Asset request for each contractor
• Asset purchase for the total request amount
• Parallel Istisna Bills receipt and Bills payment processing
The system also supports retention amount for each bill and reversal of retention amounts.
Islamic Banking - Islamic Over Draft

Description:
New feature added in which the system allows the sweeping from and to a current account based on
balance availability
Value Proposition:
Islamic Over Draft is linked to Mudaraba Account with fixed profit rate. Contract with at maturity
Principal and profit payment as monthly basis to be created. The Principal of the Islamic Over Draft is
settled at maturity and the profit is posted to the Current Account on a monthly basis. Same for the
profit amount generated from the Mudaraba Account. It should be posted automatically to the
current account.
The system allows the sweeping from and to a current account based on balance availability
Islamic Banking - Islamic Over Draft

Description:
New enhancement in finance product based on Mudaraba concept with feature to capture the actual
and expected profit is developed
Value Proposition:
Existing Mudaraba finance at present supports Mudaraba based financing without the Asset request,
Asset Pre Approval and Asset Purchase.
The Corporate Mudaraba product now comes with the additional features of placement of Mudaraba
facility which raised contingent entries, amendments to the placements, Mudaraba finance bookings,
Finance Amendments and PD processing.
Additional functions includes recording Estimated Profit, Actual profit declaration and the related
adjustment accounting entries are included. Also the manual impairment operations, Non Sharia flag
maintenance and NPA toggle field is included.Profit Declaration functionality is available
Islamic Banking - Diminishing Musharaka

Description:
Enhancement in Diminishing Musharaka is a partnership contract in which one of the partner

promises to buy the equity share of the other partner until the equity is completely transferred.
Value Proposition:
Existing Musharaka process flow and functionality is available in both retail and corporate Islamic
products suite
iminishing Mushharaka is an additional product which has the process flow Asset Request, Asset Pre
Approval, Asset Purchase, Reposses and Past Due operations. Necessary reports and enquiries to
demonstrate the diminishing asset details and Profit and expense declaration functions are added.
In addition, to the above the functionality, Profit Declaration functionality is also available.
Islamic Banking - Diminishing Musharaka

Description:
Enhancement in Islamic Finance adding Musawama which adds value to the existing Islamic products
suite built as per Sharia.
Value Proposition:
A new product is added to the Islamic products list.
In Musawama the cost price of the asset is not revealed to the client. All other features are similar to
Murabaha.
Islamic Banking - Enhancements for Islamic Letter of Credit

Description:
Enhancement in the Islamic LC offerings is in sync with the Conventional LCs and any changes to the
Conventional LC applications are automated in Islamic LC versions. Also minimum changes are
required in Islamic LC versions
Value Proposition:
Earlier import LC finance details were separate from the LC issuance versions
In R14,The finance details for Import LC are part of the LC issuance version for all types of LCs – sight ,
Usance , Mixed payment and Negotiation.For Musharaka LC, Profit Declaration functionality is
introduced.
Islamic Banking - Enhancements for Islamic Treasury

Description:
Double PFX - A new product under Islamic Treasury is added.
Value Proposition:
Double PFX deals involves both Obligor / Promisor. During a maturity date only one party honours
PFX deal and thus two PFX deals are created
• The Promissory FX (PFX) is a written, dated and signed instrument by a party containing an
unconditional promise to enter into an agreed foreign exchange contract with another party at a
specified future date.
• Under the double PFX, both parties (Obligor/Promisor) promise to buy/sell, however, on maturity,
only one party honours the PFX Deal, hence, two PFX Deals are created whereby one is exercised at
maturity and the other one is cancelled.
• The system is built to authorize the second deal upon authorizing the first deal at the time of
opening the Double PFX deal.
• Also amendments done to one PFX should automatically affect the second PFX.
• If one PFX is reversed before the Maturity Date, then the second one is automatically reversed as
well.
• On the Maturity Date, and before the COB, the user should be able to access one of the PFX and
choose which one to be exercised.
• During the COB, the one that is marked to be exercised is processed and the second one is
reversed.

Description:
Islamic Deposit plan- IDP is a Islamic deposit product where the bank acts as an agent for buying the
commodity on SPOT and sells on deferred basis.
Value Proposition:
Prior to R14,Reverse Murabaha product process flow and functionality was available.
In R14,
New product IDP – Islamic Deposit Product functions is built around the existing reverse Murabaha
product.
IDP handles additional functionalities like MMIIA processing, Hypothecation flag updations,
validations, other validations at Asset request, Asset Purchase, Broker accounting, reporting and
advice format

Description:
MCF Murabaha Customer Finance-MCF is structured as Commodity trade transaction to comply with
Shariah principles, for customers looking to finance their operations in the Islamic way.
Value Proposition:
Prior to R14,
Commodity Murabaha product functions were available.

In R14,
Murabaha is a sale contract between the bank (as a seller of goods) and client (as a purchaser), based
on the disclosure of initial price to client. Bank purchases goods at spot value, at the request of the
client and then sells the goods on credit at a maturity agreed marked up price.
The process flow is also added with MMA processing and necessary validations, Reports, advices and
accounting.

Description:
Islamic Structured Deposits(ISD)- A new product ISD in combination with Murabaha and derivative
(Arboon) deposit structure is included in the Islamic products suite.
Value Proposition:
The Islamic Structured Deposit is a combination of Murabaha Deposit Structure and derivative
(Arboon) that are co-mingled where the large portion of the Investment amount is invested in
Murabaha Deposit and for the remaining amount customer gets allocated to the derivatives

Description:
Bulk Tawarraq-The enhanced function is added as a separate product under the Islamic treasury
product suite
Value Proposition:
Prior to R14,
The Bulk Tawarraq product for single and bulk commodity purchase were available.
In R14,
The existing Bulk Tawarraq product is enhanced and additional functions on commodity to capture
broker details and the account details with validation and messages is added.Inventory management
for the Commodity, Broker accounting, Commodity blocking etc. is added. Management fees, Broker
fee functionality is updated

Description:
Profit Free Loan-This product is added in the finance profit of Islamic products suite where the period
for early payment can be parameterized
Value Proposition:
Prior to R14
Simple Qard Hassan an existing Profit free loan is available in the Islamic products suite. The loan is
offered Profit free and the repayment can be at maturity or scheduled.
In R14
In the Profit free loan, the period for early payment can be parameterized.Based on the
parameterization, in case of early payment of the loan before the profit free period, the client
benefits the profit free finance. Related reversals and accounting is added. Normal profits is applied
in case the repayment exceeds the free time.
Enterprise Framework- Data Framework Enhancements

Description:
Enhancement in Direct Connect Driver (DCD) to support Multiple Databases.
Value Proposition:
Previous Direct Connect Drivers can only configure and connect to a single database. It can create
tables on one database. All the tables created are read-write tables.
In R14,
The Direct Connect Driver (DCD) is enhanced with the following functionality:
• Allows configuring multiple (up to 10) databases using config-XMLxxx utility.
• Support creation and deletion of tables in different databases.
• Support creation of READ-ONLY tables.
• Support read/query tables in different database
• Should not allow update to tables in read-only tables. Should result in a core dump.
• Support creation of ASSOCIATE tables to join/view tables of both “live” database and other
databases.
• Support external indices for tables in other databases.
Enterprise Framework- Data Framework - New feature

New Feature in R14 of DATABASE ARCHITECTURE
Description:
New feature introduced as Table Generation Utility to separate transactional data from reporting
data using the information from ARCHIVE application of T24.
Value Proposition:
Table Generation Utility splits up the data using different criteria and stores the relevant information
in different tables. The data is not only split up as non-volatile and volatile, it is also split up based on
the company mnemonic.Data separation would be more beneficial in terms of performance of the
database and the maintenance of the data.
Enterprise Framework-New feature in Data Framework

New Feature in R14 of DATABASE ARCHITECTURE
Description:
New feature introduced as Scripts Generation Utility to create database scripts for the underlying
database using the information gathered by the Table Generation Utility
Value Proposition:
Earlier only one database was used to store and maintain the T24 data. So configuration of the
database was done manually. Maintenance of the data in the database was the responsibility of the
DBA and was done through the scripts created by the DBA
In R14,
The scripts/procedures to configure multiple databases are automated using this utility. Automated
generation of scripts reduces the density of errors. Standardized names of the elements/data of the
databases help the DBAs to regulate and optimize the databases better
It has the following functionalities as well
• It creates scripts to be executed both on “live” and “RO” databases.
• It creates scripts to create/delete elements of the databases.
• It creates scripts to move the data from one database to the other.
• It creates scripts for maintaining and cycling of data.
• Creates the scripts depending on the retention period of the data mentioned in the config file.
• Creates scripts depending on the MNEMONIC of the COMPANY.
• Utility can be restricted for only companies and files specified in the RestrictedFiles and
RestrictedCompany of DF_SEPARATION\config folder
• Similarly utility can exclude creation of scripts for the companies and files specified in the
ExcludedFiles and ExcludedCompany of DF_SEPARATION\config folder.
Payments - Support for IBAN Plus

Enhancement in R14 of Retail Banking
Description:
T24 is enhanced to support the new SWIFT IBANPLUS Directory and EXCLUSIONLIST file.
Value Proposition:
Prior to R14,T24 supports the upload of the BICPlusIBAN Directory and the information contained in
this directory is mapped into the T24 application DE.BIC. The BICPlusIBAN Directory is downloaded
from swift and uploaded into T24 using the DE.BIC.LOAD mechanism.
In R14, The BICPlusIBAN Directory is being phased out and upgraded to multiple new SWIFTRef
directories.
Payments - Support of Bank Directory Plus

Description:
T24 will be enhanced to support the new Bank Directory Plus.
Value Proposition:
Prior to R14, T24 supports the download of the BICPlusIBAN Directory. The information contained in
this directory is mapped into the T24 application DE.BIC. The BICPlusIBAN Directory is downloaded
from swift and uploaded into T24 using the DE.BIC.LOAD mechanism.
In R14,The BICPlusIBAN Directory is being phased out and upgraded to multiple new SWIFTRef
directories.
Payments - Derive BIC from IBAN

Description:
A feature to automatically derive and default the BIC code from the IBAN of the Beneficiary to
facilitate the successful remittance of the Outgoing Payments.
Value Proposition:
Prior to R14, BIC code wont get default from IBAN of the Beneficiary.
In R14, it will be possible to automatically derive the BIC code and the related Institution Name &
Country of the BIC from the IBAN that has been entered in the Outgoing Payments.
Payments - Mapping of BIC.IBAN.BEN.NAME and BIC.IBAN.BEN.CITY to

57D
Description:
When the system is unable to derive a BIC code from an IBAN, it is possible to manually enter the
information and can be mapped to the ACCT.WITH.BANK field and ultimately mapped to field 57D.
Value Proposition:
Prior to R14, The fields BIC.IBAN.BEN.NAME and BIC.IBAN.BEN.CTRY when manually entered, are for
information purposes and will not be mapped into 57D.
In R14, The field BIC.IBAN.BEN.CTRY is renamed to BIC.IBAN.BEN.CITY of the BIC.IBAN.BEN. The

information will be mapped from the CITY field of the DE.BIC table when defaulted.
When there is no value in the field BIC.IBAN.BEN, the user is able to manually input the fields.
•BIC.IBAN.BEN.NAME
•BIC.IBAN.BEN.CITY
It is required that the values of these two fields be mapped in tag 57D
Swift - Swift 2013 Changes

Description:
this enhancement is to include the country Code ‘IL’ to check if Sender/Receiver Bank Country is ‘IL’
for making IBAN as mandatory in the field 59A Beneficiary Customer, subfield Account during the
generation of MT103+.
Additional feature is being introduced to validate the IBAN populated in the Tag 59 A Beneficiary
Customer (Subfield Account) if the Sender and Receiver BIC belongs to the European List of Countries
Value Proposition:
This functionality built in R14, it is possible to make the IBAN validations as mandatory in the field
59A Beneficiary Customer, Subfield Account during the generation of an MT103+ whenever the
Sender & Receiver Bank and (or) Account with Bank country code is either ‘IL’ or belongs to the
European union list of Countries that is maintained in a separate table.
Standing Order - Percentage of Amount to be transferred to BO STO

Description:
This enhancement is to define a % value for Balance Out type STOs to arrive at the transfer amount.
During execution of the STO, this percentage is applied on the excess amount that needs to be
transferred.
Value Proposition:
Prior to R14, it is not possible to specify the percentage of amount.
In R14, It is possible to define a percentage of the excess amount that needs to be transferred during
the execution of the Standing Order to the Counter-party Account.
Standing Order - Priority for STO Execution

Description:
This enhancement is to define a Priority Number for Fixed (FI) type STOs which determines the Order
of Processing of the STO during Batch Process.
Value Proposition:
Prior to R14, it is not possible to specify the priority for Fixed(FI) type STOs.
In R14, It would be possible for the Bank to define a Priority Number for the FI type STOs that have
the same execution date, held by a Customer Account which will be processed in that order during
the Batch process. This will be useful for the Customer to prioritise his payments against the
Available Balance maintained in the Account.
Position Management - Treatment of an Amortizing Interest Rate

Swap on Floating Rate leg side
Description:
Projection in Interest Rate Gap report, on account of floating rate leg side of an amortizing swap,
with current interest rate is debatable since the residual principal amount is due for a rate resetting
at the end of the current IP/Amortizing schedule period.
Value Proposition:
Prior to R14, In the Interest Rate Gap report of PM, the projection on account of an amortizing Swap
for both floating and fixed legs is done the same way, i.e each amortized amount is shown in the
respective time bucket with interest rate as applicable for the current period. While it is fine with
fixed rate leg, the projection with the same current interest rate on floating rate side is not
considered correct by some banks.
In R14, The Interest Rate risk on account of an Amortizing swap will be correctly reflected in the
report as and when the Asset or Liability undergoes a rate resetting.
Money Market - Interest Spread while inputting an MM contract

Description:
This enhancement introduces an option to capture the Interest Spread at the time of inputting an
MM contract with fixed rate and fixed maturity, which has a defined PI key.
Value Proposition:
Prior to R14, Interest Spread at the initial instance of inputting an MM contract with Fixed Rate and
Maturity along with PI key was not allowed, unless Auto Rollover was set. And there was no logic to
include the interest spread in the Interest Rate derived from PI table. However, spread is considered
during rollovers, when ROLLOVER.INT.RATE is specified with PI key as P<INDEX>S; and it is considered
to arrive at the NEW.INTEREST.RATE for calculating the next interest amount.
In R14, Interest spread is captured at the time of input of a fixed rate type of MM contract which has
a defined PI key. Interest Rate is derived after the summation of the derived PI.INT.KEY and the
defined Interest Spread.
Forex - Automatic Defaulting of FX Margin

Description:
A new functionality is added to the Forex application using the existing framework of Condition
Priority, Gen Condition and Group Condition.
Now the User could define the margin % by deal type. Customers or Customer Portfolios can be
grouped based on certain conditions defined in Condition Priority and the values for each of the data
elements in FX.GEN.CONDITION. The Margin applicable for each such group is defined in a table
named ‘FX.GROUP.CONDITION’.
Value Proposition:
In R14, this new functionality offers flexibility to define and to automate the application of FX
Margin/Spread to derive customer rate based on defined criteria.
Loans & Deposits - Limit Update and Accounting Changes

Description:
This new enhancements provides following new features in Loans & Deposits module ,
•Limit could be updated for both the Principal amount and the Interest portion.
•Accounting entry for the interest portion at the time of contract booking
Value Proposition:
Prior to R14, this features are not available.
In R14, this new features helps to update the limit for both principal amount and interest amount
and also raise a accounting entries for interest portion at the time of contract booking.
Lending - Simulate Arrangements and Compare

Description:
This new functionality is based on the list of simulation available with the arrangement. It allows the
user to compare two or more simulated arrangements to an existing contract and helps user in
choosing the best arrangement.
Value Proposition:
Prior to R14, two simulated arrangements can be carried out only using two simulated overview
screens.
In R14,users can compare the simulated arrangements and can print the comparison results on a
Single Screen.
Lending - Loan Enquiries for Limits and Collateral

Description:
This usability improvement displays the Limit and Collateral information of the customer at the
Arrangement overview screen level, and retrieves the arrangement records based on limit and
collateral reference IDs.
Value Proposition:
Prior to R14, Limit Amount, Expiry Date and collateral information of the borrower could not be
viewed in the Arrangement overview screen.
In R14, the arrangement overview screen displays the Limit and Collateral information of the
customer and retrieves the Arrangement records based on the Limit IDs.
Lending - Tax on Interest

Description:
The improved functionality allows user to define tax on any charge or interest.
Value Proposition:
Prior to R14, Tax property class not part of Lending product line, hence there was no functionality to
define tax for Lending products
In R14, the TAX property class is now introduced into the Lending product line. The function
calculates tax during Issue Bills, Make due, Capitalise for respective Interests or Charges. The
calculated tax is updated against the TAX property in the bill.
Lending - Rate Change Set in Advance

Description:
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.
Value Proposition:
Prior to R14, this features are not available.
In R14, The ADVANCE.RATEFIX.PERIOD field is now introduced in the Product Designer. In this field,
user can set the period before which interest rate should be fixed for scheduled Periodic Reset and
scheduled “Change Interest” activities.
Core AA - Transaction Recycler

Description:
When there is no sufficient funds in the settlement account, the new functionality provides a failed
transaction and retries them in the specified frequencies.
The failed transactions are retried using Recycler (RC) service which is executed as a CoB job in a
specific stage both during END.OF.DAY (EoD) and START.OF.DAY (SoD). This CoB job retries the
transaction on a scheduled date until the transaction is settled or the number of permitted retry
attempts are exhausted or when the end date for retry is reached.
Value Proposition:
Prior to R14, if the bill that is made due is not settled from the settlement account due to insufficient
funds in the account, there was no automated feature to try a failed transaction on a scheduled
frequency.
In R14, The Retry logic attempts several automated retries to collect funds from the funding source
on a scheduled frequencies.
Core AA - Document Management

Description:
The new functionality allows the user to capture and upload (store) the documents and images at
arrangement level for loans, deposits and accounts products.
Value Proposition:
Prior to R14, Document Management is configured only for the customer application and there was
no configuration for AA Products.
In R14, user can view the documents and images provided for the arrangement in the arrangement
overview screen for AA products.
Core AA - Restricting Backdated Activities

Description:
This improved functionality provides flexibility to the bank in restricting the backdating of events
prior to current billing period and current billing period as well. The criteria for the restriction are
Billing Period, Account Statement Period, Actual Period, Specific Date and Renewal Period.
Two types of restrictions could be implemented, they are:
•Error
•Override
Value Proposition:
Prior to R14, backdating was supported through reverse and replay mechanism and there were no
restrictions to it.
In R14, This is an option for banks to restrict the backdated events for a specific period as defined by
user.
Core AA - Multiple Charge Entries

Description:
The new functionality generates and reports tax entries by portfolio or group them to categorize by
customer relationship.
Value Proposition:
Prior to R14, There was no provision to group and generate report based on the tax split defined in
customer relationship table or portfolio by ID.
In R14, Generate tax entries by portfolio and group them by customer relationship.
Core AA - Defining Relationship Products with Preferential Rates

Description:
The new product line ''RELATIONSHIP PRICING'' deals with how customers get differential rates
based on their relationship with the bank
A “PREFERENTIAL.PRICING” property class is introduced as a part of the new product line.

Value Proposition:
Prior to R14, in AA there were two ways to offer preferential pricing:
•Promotional Pricing
•Products with Eligibility Criteria
In R14, Preferential Pricing has been introduced as part of new product line.
Core AA - View Joint Ownership Information

Description:
AA enquiries now display Joint ownership information under Single Customer view.
Value Proposition:
Prior to R14, this does not display the joint ownership information.
In R14, AA enquiries are enhanced to search and display the arrangements where the customer is
also a joint owner of an arrangement. In order to display the arrangements that is owned by a
customer (irrespective of customer being the primary/sole borrower or a joint borrower) a new
multi-valued field OWNER is added to the AA.ARRANGEMENT application.
Internet Banking - Multiple Language Support

Description:
TCIB suite is now capable of supporting multiple languages using simple language mapping features.
Value Proposition:
Previous TCIB releases did not supported multiple languages functionality.
From R15 , TCIB is equipped with multiple-language functionality that currently supports
configuration of two languages (the default English language and French) without modifying the
project files in use. By default, users are now presented with the two different languages and users
can choose to switch between languages from links at the top of the page. Changes to the project
files are required only if more than two languages are added.
Internet Banking - Unified User Management

Description:
Configuring the user accounts for both AA and Non-AA products are now unified and simplified
Value Proposition:
Previously, the user management solution supported AA or Non AA products in two different ways.
AA-based product configuration depended on the arrangement creation while Non-AA solution
depended on the channel profile template.
With the new functionality from R15, configurations for both AA and Non-AA products are now
merged and the Integration Framework is effectively used to send permissions as defined in T24 to
TCIB Solutions.
To aid the new user management solution, a new product line in now introduced specifically for TCIB
Products in the internet product services line. The Product Group template can now be used for
setting up both AA and Non-AA products. All Non AA Product groups are now created under product
line 'OTHER'.
TCIB Product Group : A new Arrangement creation presentation property has been specifically
designed for TCIB with TCIB versions containing fields relevant to TCIB solutions.
Internet Banking - Secure Messages with Attachment

Description:
Bank users are now able to upload any documents to the TCIB users while TCIB users can now
download attachments.
Value Proposition:
Previously, the facility to upload attachments while composing a secure message in T24 is not
available.
From R15 , The Secure Messages functionality is enhanced with File Uploading feature. Using Secure
Messages, now the user can upload documents or images to the Internet Banking user. When the
Internet Banking users receive messages, they are now able to download the attachments. To
download, the 'Download Attachment' button is now introduced in the Messages functionality.
Internet Banking - Self-registration at First Login

Description:
TCIB users are now able to self-register their token devices at first login
Value Proposition:
Previous TCIB releases has no device binding functionality.
With this new functionality from R15, the new external users of TCIB has to login with the
authentication code provided by the bank to set their own password / pin / memorable word based
on the login type. External users logging in for the first time are allowed to set their own password /
pin. This is available for the external user type and not available for the internal user maintained.
User's logging in are verified with their EB.EXTERNAL.USER>STATUS field. If the status equals to
Initiated, TCIB will navigate to the registration page.
Internet Banking - Temenos Connect Internet Banking - Wealth

Description:
TCIB Wealth provides comprehensive front-office functionality for a fully integrated Wealth
Management solution
Value Proposition:
There are no major changes to functionality. TCIB features all major functions that are present in ARC
IB suite.
From R15 , Delivered through a web-based interface, TCIB Wealth provides a flexible front-office
platform with tools for client management, asset allocation, financial planning, investment
management, trading, reporting and compliance. This is an end-to-end solution tailored for banks
and independent wealth management firms, providing integrated tools and services.
This comprehensive wealth management system accommodates the following functionality:
1) Client and Relationship Management tools
2) Flexible asset classification tools
3) Order management tools
4) Multi-level performance analysis and risk metrics
5) Consistency through pre-designed reports
6) Business analysis for accurate decision making
7) Performance and Investor Reporting
8) Portfolio Management
9) Trading and Accounts management
Internet Banking - Loans and Deposits in TCIB Corporate

Description:
TCIB Corporate now supports the Loans and Deposits functionality
Value Proposition:
The TCIB Corporate solution is now enhanced with the Loans and Deposits function which was
previously available only in TCIB Retail. Users are now able to initiate the LD function on defining the
"LD_FLAG" in their Corporate.dsf file.
Mobile Banking - Temenos Connect Mobile Banking

Description:
The TCMB Retail is a mobile banking application providing rich pre-configured retail functionality fully
integrated to Temenos' leading core banking platform T24
Value Proposition:
TCMB Retail is a mobile banking application providing rich pre-configured retail functionality fully
integrated to Temenos' leading core banking platform T24 and is powered by Temenos UXP
edgeConnect. TCMB Retail has been developed using Temenos' ground-breaking SmartHybrid™
technology solution for developing mobile applications that provide a near native experience with
fully optimised performance and security.
TCMB Retail is a SmartHybrid™ app combining the very best of native and web technologies. This
enables the mobile banking app to fully utilise the device specific features to provide the richest
native experience for the customer whatever phone they choose to use. Enhancements to the TCMB
app can be made and published once without the need to redistribute the app to multiple app
stores. This enables banks to be very agile in responding to market opportunities and customer
demands, with quick speed to market and reduces the complexity and cost of managing and
distributing multiple apps for various devices.
Retail - Arrangement Architecture - Core - Commission Processing

Description:
An end to end commission processing functionality that includes calculation and clawback of
commissions.
Value Proposition:
Previously, in Arrangement Architecture commission calculation were dealt by configuring a CHARGE

property and crediting a designated account. However, the functionality was limited and was not
scalable to the changing market requirements.
Retail - Arrangement Architecture - Core Separate Tax Entries for AA

Account
Description:
In AA, tax can be posted separately and it is possible to raise two different accounting entries for tax
and base amount in account.
Value Proposition:
Prior to R15 , In AA accounting, tax can be configured to be calculated on Interest and Charge
properties. Individual Interest or Charge property can be linked to actual tax / tax type condition. Tax
was calculated every time when the corresponding Interest or Charge is made due or capitalized.
Retail - Arrangement Architecture - Core - Broker Administrator Home

Page
Description:
Broker Administrator home page allows to access the agent's information.
Value Proposition:
New R15 features are A new USER record BRADMIN is created in the system. The Home page of
Broker Administrator is added containing a menu with the Agent’s actions on the left side and on the
right side two tabs. The first tab will contain the product catalogue and the second tab an enquiry to
look for a specific agent.
It also give the details about the Agent such as Name, Customer Number, the number of Deals he
manages for the bank, total assets/liabilities, profit, and commission.
1) List of Customers the Agent is dealing with
2) List of Agent Arrangements the Agent has with the bank
3) List of Financial Arrangements the Agent has with the bank can also be viewed .
Retail - Arrangement Architecture - Core - Collections is now in Core

Description:
Collections are now moved into core to facilitate the debts collection process so that it is possible to
prevent the loss of revenue.
Value Proposition:
Loan Collections are now introduced in T24 to facilitate the debts collection process. Collection
process includes collecting payments from those who are delinquent or who have defaulted on their
contractual commitments, that is, those who make payments later than their contractual due date
Retail - Arrangement Architecture - Accounts - Generate AR Advices

Description:
Now, it is possible to send advices to an account holder whenever an activity takes place.
Value Proposition:
The new functionality allows AR to produce advices similar to what can be seen within Loans and
Deposits. The details providing on the AA contracts are mapped for generating the required advices
based on AA activity.
Retail - Arrangement Architecture - Customer Relationship

Management - Opportunity Processing using Insight
Description:
A daily download can be obtained from Insight into T24.
Value Proposition:
Previously Opportunities could only be raised based on the transaction database of T24. T24 was
previously able to accept the PLAN data from Insight and display the data into T24 screens.

Management - PLAN Analytic and Customer profiling using Insight
Description:
It is possible to store and display the PLAN analytics data in T24 screens.
Value Proposition:
Insight provides additional customer intelligence such as profitability, loyalty, attrition risk and
number of products. These can now be stored in T24, so that bank staff are aware (through an
innovative ‘galley light’ system) of this customer intelligence when they are handling the client, and
responding accordingly.
Internet Banking - Targeted Advert Display

Description:
A feature that equips bank to display targeted adverts to eligible customers
Value Proposition:
In R15 , TCIB is capable of displaying adverts (available opportunities eligible for a customer) to a
logged in customer. The number of opportunities to be displayed on the screen is configurable using
a global variable setting.
Internet Banking - Errors and Overrides Management

Description:
The ERROR and OVERRIDE application's field length is now increased to 150 characters, the
NUMERIC.ID is attached to the Error message and more new features for effective error and override
messages management
Value Proposition:
In the previous TCIB release, when an error occurred, T24 validated the error based on the channel. If
the channel was INTERNET, then T24 returned the error which is dedicated to that particular channel.
Override message was displayed based on the type field.
Regarding the language information, when user selected an alternative for example French, website
appeared in French while the error messages appeared in English (based on the flag in
EB.EXTERNAL.USER). With this enhancement, the issue has now been addressed.
New enhancements are
Language Information:When the language is changed within a session or prior to login, now the
Language Information is updated to the EB.EXTERNAL.USER accordingly. With this solution,if the
website appears in French, then the error messages also appear in French as against the previous
functionality where the error messages appeared in English.
Enhancements to EB.ERROR :
1) Increase in MESSAGE field's length:
2) Dynamically adding NUMERIC.ID to the message field:
3) Unmapped Errors link to a configurable generic Error Message
The actual override message is appended with Warning or Message based on the type of the
override to identify them in the webservice response as both the types stored in the same override
field.
TCIB front-end enhancements were also made to Error and Override Message.
Internet Banking - Enhanced Integration with an Authentication

Provider
Description:
Enhanced User Management capabilities and improved integration with an Authentication Provider
using ActivID® Authentication Appliance. (Note: ActivID® is a registered Trademark of HID Global.
Value Proposition:
Prior to R14 , after the deactivation of users (INACTIVE status), the user record from authentication
provider was not deleted subsequently.
From R15 , a new attribute has now been created in a third-party Authentication Solution (ActivID®
Authentication Appliance) for storing the User channel's Status and the Login Method. Every time, if
there is a change in the EB.EXTERNAL.USER's channel status and Login Method, the authentication
solution's attributes are updated correspondingly.
An EB.EXTERNAL.USER has the following STATUS's (Note: Each status is per Channel)
INITIATED indicates creation/recreation of user, initiation of device binding process and creation of a
user record in Authentication Solution.
ACTIVE indicates that a user can access the system via a particular Channel
BARRED indicates that the access for the user is blocked on a particular Channel temporarily.
INACTIVE indicates the access for the user is blocked on a particular Channel.
<blank> blank option is not a valid option but presents in the version.
When all the channel status is set as “INACTIVE” and the field ‘Delete EEU Record ‘ value is set to
‘Yes’ in CHANNEL.PARAMETER , then External user record will deleted from third party server. In
EB.EXTERNAL.USER, Channel can be deleted, when the channel status is set as “INACTIVE” or an error
message is displayed during validation.
Retail - Arrangement Architecture - Core - Credit and Debit Charges

Grouped in PERIODIC.CHARGES
Description:
Feature includes option to group both Debit and Credit charges, and now the credit charges can be
offset against the debit charges.
Value Proposition:
Previously, an instance of PERIODIC.CHARGES was included in PAYMENT.SCHEDULE to define the

frequency for the consolidated fee that has to be charged on the arrangement. They can be
capitalized or collected or paid on an arrangement.
With the improved functionality from R15 , the PERIODIC.CHARGES property class allows grouping of
Debit and Credit charges and offsets the credit charges against the debit charges.
The solution also entails:
Two new fields named MIN.CHG.AMOUNT.CR and MAX.CHG.AMOUNT.CR are now added to the
PERIODIC.CHARGES property class to define minimum and maximum credit charges to be applied if
the evaluation of periodic charges results into a credit.
MAX.CHG.AMOUNT.CR - Defines maximum charge amount to be paid for the currency attribute if the
net charge amount is a Credit.
MIN.CHG.AMOUNT.CR - Defines minimum charge amount to be paid for the currency attribute if the
net charge amount is a Credit.
Retail - Arrangement Architecture - Core - Deferment of Payment

Schedule
Description:
Scheduled payments can be deferred before making it due
Value Proposition:
Previously, the scheduled payments for an arrangement for the financial properties namely interest,
charge, principal and periodic charges were defined using the property class ‘Payment Schedule’. On
a scheduled date, bills for valid property amounts were created and the accounting entries were
raised, thus making the amount due or paid, or the amount was capitalised.
With the new functionality from R15, the interest, charge and periodic charges can be reviewed and
scheduled payments can now be deferred by number of days before making it due. Simply, the bill is
generated but deferred for some days before making it due or pay or capitalising the amount.
The solution also entails the DEFER.PERIOD attribute in payment schedule to define the number of
days to be deferred. The functionality offers the ability to perform an analysis on specific
transactional accounts in AA to manage transaction based fees. This analysis details the fees that are
assessed against an account and projects the amount of interest that could be earned by the bank
(i.e. the profitability from the balance maintained in the account). The feature also allows the user to
offset the calculated interest earnings against the charges assessed.
The customer is charged only for the deficit in earnings credit when compared with the gross charges
assessed. If the earnings credit is more than the charges assessed, then the bank do not pay the
excess to the customers.
Retail - Arrangement Architecture - Core - Charge-off

Description:
Option to apply full charge-off or partial charge-off with dual accounting features and more…
Value Proposition:
Previously,
1. There are no options to apply charge-offs.
2. AA allowed writing-off an entire balance or an entire bill. This was accomplished through specific
activities of the Balance Maintenance property class.
3. For payment application, a user had to specify the order that a payment is applied to bills and
balances through the Payment Rules property class. This property class allowed defining a single
sequence and did not allowed different rules to be used when a loan is in non-accruing status.
Following are the new functions introduced in AA Lending in R15 to support the charge-off feature:
1. Charge Off Activity
2. Charge Off Balances
3. Customer Balances
4. Multiple Interest Accruals
5. Dual Billing
6. Charge Off Property Class
7. New Accounting Events
8. Restrictions to Credit Arrangement
9. Dual Accounting
10. Partial Write-Off
11. Different Repayment Order for Non-Accrual Loan
Retail - Arrangement Architecture - Core - Interest and charge

calculation based on limit amount
Description:
Enhanced REFER.LIMIT field allows the calculation of interest and charge based on the limit amount
sanctioned to the customer
Value Proposition:
Prior to R15 , The REFER.LIMIT field can be indicated to have different calculation rates for interest
and charge, when the utilization is within the limit / exceeding the limit.This field could be defined to
have tiered interest / charge definitions based on the LIMIT amount sanctioned to the customer.The
TIER.AMOUNT.1 would be dynamic & was calculated when charge or interest is calculated.
From R15 the REFER.LIMIT field has been enhanced to allow interest and charge calculation to refer
the limit amount sanctioned to customer on setting the field as YES. Interest calculation based on
online limit is now fully supported in AA, whether the limit is created by AA or manually created in LI
module.
When an arrangement is created with REFER.LIMIT value, LINK.TO.LIMIT field is updated in ACCOUNT
template to create a record in ACCOUNT.DEBIT.LIMIT for the arrangement. Records in
ACCOUNT.DEBIT.LIMIT (ADL) are dated and any change to limit amount are updated as a new record
during the SOD stage of COB. This feature is supported only for single limits & is restricted for shared
limits. The functionality has now modified the AA processing to consider the ADL for tier amount
when the REFER.LIMIT value is set.
Retail - Arrangement Architecture - Core - IJARA Product Spread Rate

Change
Description:
In LD, it is now possible to calculate rate revision, spread change and total interest amount change.
Value Proposition:
Prior to R15 , two existing fields namely LIVE.INTEREST and UPDATE.LIMIT.INT, in

LD.LOANS.AND.DEPOSITS application, are:
LIVE.INTEREST – When this field was set, an accounting entry with asset type LIVEIN would be raised
for the total interest amount on contract booking.
UPDATE.LIMIT.INT – When this field was set, like principal component limit would also be updated
for the total interest amount on contract booking. During repayment of interest, limit would get
reinitiated to the repaid interest amount for revolving limit.
The interest amount could not be changed even if there were changes to the repayment date or
Partial payment paid by the customer and hence rate change, spread change and interest amount
were restricted during life of the contract with LIVE.INTEREST or UPDATE.LIMIT.INT setup.
From R15 ,whenever a new rate / new spread is defined in LD template, system computes the
difference between the old interest amount and new interest amount, and accounting entries would
be raised for the adjusted interest amount. So, Rate revision and Spread revision are allowed for the
Fixed rate contracts with LIVE.INTEREST setup.Accounting entries can be generated for the adjusted
interest amount due to rate / spread change. Limit can be updated for the adjusted interest amount.
Retail - Arrangement Architecture - Lending - Rate Change Set in

Advance - Anniversary
Description:
Define the effective base date and the future dated rate change for an interest property from the
arrangement Level.
Value Proposition:
The solution deals with the newly introduced ANNIVERSARY option under the EFFECTIVE.BASE field
of the AA.PRODUCT.DESIGNER application. A user can define the effective period of the next
condition in this EFFECTIVE field.
The ANNIVERSARY option is applicable for all FORWARD.DATED conditions. When creating a new
arrangement, the ANNIVERSARY condition is displayed in the screen. A user can amend the definition
of the product level condition.
Retail - Arrangement Architecture - Lending - Rebatable Insurance

Description:
Option to define the grace period, rebate calculation on cancellation of an insurance contract and
insurance portion rebated on pre-closure of a loan.
Value Proposition:
Previously, there were no functions to:
1) Define a grace period for charge amortisation
2) Rebate the unamortised amount of the loan
3) Allow a user-defined API to replace the system calculated amortization amount
4) Modify the amortization start date, based on user defined logics
The newly introduced functions in R15 are as follows:
A new rebate property - Insurance
Among the number of CHARGE properties associated with a loan product, only few have the
requirement for rebate. To distinguish the properties with rebate functionality, a new property type
named INSURANCE is now introduced.
Defining Grace Period and Accrual Rule
A user is now allowed to define the grace period using the newly introduced Cancel Period field of
the CHARGE property class. Additionally, the value in the newly introduced Accrual Rule field
determines the Charge amortization period (i.e. the start date and the end date). The Accrual Rule
configuration is based on the EB.ACCRUAL.PARAM records which also allows the usage of an user-
defined amortization algorithm. The solutions covers the determination of rebate (on insurance
portion of the loan amount) for the following:
1) Cancellation of an Insurance Contract
2) Pre-closure of a Loan
Retail - Arrangement Architecture - Lending - Bill Settlement in

Advance
Description:
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.
Value Proposition:
To aid the new feature, a new payment rule type named ‘Advance’ is now introduced in the
AA.PAYMENT.RULE.TYPE. Setting the ‘Advance’ option as the type results in generating the bills in
advance. The advance bill generation is allowed only if the System Bill Type field is set as ‘Payment’ in
the BILL.TYPE. If the BILL.TYPE is used for payment type other than the CALC.TYPE
LINEAR/CONSTANT/PROGRESSIVE, it is not be considered for processing.
The repayment of a past due bill is primarily appropriated on the interest balance (billed & accrued)
and then the remaining amount is settled on the principal. The past due bill is considered settled only
if the payment amount is equal to the past due bill amount.
Retail - Arrangement Architecture - Lending - Minimum Payment

Amount
Description:
Users now can specify the minimum payment amount by bill type.
Value Proposition:
Previously, AA allowed minimum amount definition for Interest and charge property by defining the
minimum amount in the interest and charge product conditions.
Retail - Arrangement Architecture - Lending - Payment Tolerance

Description:
Option to set the tolerance by bill type and the tolerance is now considered in a total settlement.
Value Proposition:
Previously,
1) The tolerance could not set per bill but was rather set as a cumulative tolerance.
2) The tolerance could not be specified only for instalments.
3) The tolerance setup was ignored from a Bill Total settlement.
With this improved feature in R15, now the users can set tolerance limit by bill type. To aid this
feature, the tolerance fields are now introduced in the BILL.TYPE.If the Bill Settlement field is set as
Bill Total, the Payment Tolerance is considered for determining the settlement status of a bill and any
future payment does not affect the bill .
Retail - Arrangement Architecture - Lending - Interest Payment in

Advance
Description:
The banks can now pay the total interest amount in advance at a predefined date
Value Proposition:
With this new feature, now banks can create deposit products in which the total interest amount can
be calculated in advance and paid to the customer at a predefined date, for example 15 days from
the funding of the deposit.
Retail - Arrangement Architecture - Lending - Pay-off Tolerance

Description:
It is now possible to manage the payoff tolerance as an absolute amount or a percentage of the full
payoff amount.
Value Proposition:
Previously, the ability to define a tolerance limit was available only for overdue processing
With the improved functionality in R15, user is allowed to define a tolerance limit in the PAYOFF
Property Class using the four newly introduced fields. A user can also define the action to be taken
on Payment shortage.The following four fields are now introduced in the PAYOFF Property Class:
TOLERANCE.PERCENT – user can define the tolerance in terms of percentage of the total payoff
amount.
TOLERANCE.CCY – this is to define the currency for currency specific tolerance amount.
TOLERANCE.AMOUNT – this is to define the currency specific absolute tolerance amount.
TOLERANCE.ACTION – this is to define the action for the shortfall within the defined tolerance limit.
It can be either set as ‘Remain’ or as ‘Write Off’.
Retail - Arrangement Architecture - Lending - Amortisation until

renewal of product date
Description:
Now, Charge / Periodic charge income / expense can be amortised until the product renewal date.
Value Proposition:
Previously AA supports Amortization of charges through the fields ACCRUE.AMORT and

ACCRUE.PERIOD in Accounting property class. A charge can be configured to be amortized over a
fixed period or until maturity date.
Retail - Arrangement Architecture - Bundle - Interest Compensation

Description:
In a Bundle, it is now possible to donate both Credit and Debit balances, accrue interest for
information purposes and can capitalise any accrued interest at will.
Value Proposition:
Previously below mentioned functionalities were not avaialble .
In R15 the below listed new features are available
1) The new feature allows specifying multiple credit balances and debit balances for each donor.
2) In the new enhancement, closing a product bundle is possible.
3) A donor can be removed by delinking from the product bundle. To change the recipient, the
existing recipient needs to be delinked and the new recipient should be uploaded.
4) Backdated transactions (on donors and recipient) are possible resulting the
recalculation/adjustment of accrual interest (for current period), or capitalised interest and accrual
interest (for previous period).
5) Donors can continue maintaining accrual details (in AA.INTEREST.ACCRUALS field) only for
information purpose by setting the Accrual property as Info Only.
6) The definition of product bundle is enhanced to allow specification of participants at the product
level. In product bundle, a new field “Product” is added which is used to restrict the type of products
.
7) Now, it is possible capitalising the interest on any interest property.
Retail - Arrangement Architecture - Accounts - Overdraft Ageing

Process for Retail Accounts
Description:
There is the ability for a Retail account to go through an Overdraft Ageing Process, thus providing
events which will allow the configuration of Notification letters and charges.
Value Proposition:
The LIMIT Property class has been enhanced to include configuration to place an account into the
aging process. The following fields have been added
1) TOLERANCE.AMT
2) TOLERANCE.CCY
3) CUST.OD.STATUS – This can be set to either Customer or All
4) OD.PERIOD
5) OD.STATUS
This new functionality provides the ability for a Retail account to go through an Overdraft Ageing
Process, thus providing events which will allow the configuration of Notification letters and charges.

Management - Client Contact Experience
Description:
It is possible to identify the customer and have them checked in to know who is in the branch, on the
phone, online in the IM Chat or any other channel at any time.
Value Proposition:
A new ‘CUSTOMER.ENGAGEMENT’ table is introduced to improve the handling of client experiences.

This includes ‘checking in’ and ‘checking out’ clients from branches, and assigning staff to customer
requirements. This is partnered with a ‘CONCIERGE’ application developed using Edge, to provide a
smooth customer experience.
There is a facility to maintain history per customer (of which branches they have visited) using the
table “CUSTOMER.ENGAGEMENT.HIST”, an automated index file.

Management - Differentiating External users from Customers
Description:
This enhancement helps banks to differentiate external users from the banks' actual customers,
when linked to the mandates processing in T24.
Value Proposition:
Prior to R15 , T24 had a functionality to differentiate between the bank’s actual customers and the
prospective customers and not the external customers created for the sake of Internet Banking
purposes.
From R15 , it facilitates banks to differentiate an external user from that of the customer of a bank by
having a new option in the CUSTOMER application. Also, if a customer record is defined as an
EXTERNAL.USER, the same can be reversed if the corresponding customer is not used in the
applications EB.EXTERNAL.USER and EB.SIGNATORY.GROUP
Accounts - Customer and Account Mandates - Non Financial

Description:
Facility to define signatories who are required to authorise specific financial transactions based on
amount thresholds set or non-financial transactions.
Value Proposition:
Previously the Mandates functionality so far was applicable to the Funds Transfer, Standing Order,
Bulk Payments, Bulk STO and Direct Debit claims. This required the definition of the Amount fields,
which need to be looked upon during the processing of the respective transactions to determine the
Signatory requirement.
Accounts - IX Module Related Changes around Account Statement

Description:
T24 provides the ability to generate the camt reports using the same base software used for the
Account statement processing.The software provides the flexibility to support the different content
that are required for the message types and provides extensions to the processing in order to allow
customisation that will cater to local requirements
Value Proposition:
Prior to R15 , The content of the camt message could be only be configured and suppressed locally at
the individual tag. The camt message will show all the entries for the account statement or report
period but there is no possibility to select the list of entries for a specific account movement report.
From R15 the following benefits are available ,
1) Different variations of camt054 may be allowed (camt054a and camt054b) by plugging a filtering
routine to select the list of movements.
2) Customers can select entries that they want to consolidate as part of a Camt message, by applying
a consolidate API that will select the entries to consolidate.
3) Customers can suppress a block of data tags falling under a tag group and if the suppression logic
is complex, an API can be plugged in.
4) The client will have the ability to plug-in an API, to use locally defined logic to retrieve details from
local tables to be displayed in the Camt message.
Accounts - Customer Balance Reporting

Description:
The DA Module provides a read-only dimensional database with near real-time data, optimised for
query purposes. The first business model deployed is the Customer Balance Reporting Model, it
provides the ability to query on Customer, Account balances and movements
Value Proposition:
In R15 , The DA Module is the Customer Balance Reporting Model; it has been designed for the
purpose of querying of Customer and Account information and all the necessary information to
produce customer account balance queries
Accounting Unit - AU Rule LD

Description:
A new local routine helps to allocate the contracts between accounting companies
Value Proposition:
Previously , The T24 AU parameter tables already have the ability to accept a local routine that can
be used in complex allocation scenarios.
In R15 , this enhancement provide a routine AU.AMT.CCY , which can be used as an example in
complex allocation rules
Financial Accounting - Accounting Treatment for Cash Based

Transactions - Accounting Systems
Description:
It is a new Accounting treatment where cash based transactions with future value dated entries can
be reported under Receivable/Payable between the booking date and the value date with account
balances updated only on the value date
Value Proposition:
Previously , T24 supported two accounting treatments namely Trade Dated Accounting and Value
Dated Accounting.For future value dated cash based transactions under Value dated accounting, the
movements were booked as “Off Balance Sheet” item (contingent entry) from the date of transaction
until the value date. On the value date, the STMT.ENTRY was generated; the account balances were
updated and the contingent entries were reversed.
In R15 , In addition to the Trade dated and Value dated Accounting, a new accounting treatment
(Traded Dated GL Accounting) has been deployed. With this accounting treatment cash based
transactions with future value dated entries can be reported under Receivable/Payable between the
booking date and the value date, with the account balances updated only on the value date.
The Core Accounting mechanism now allows switching from one accounting treatment to another.
The switch to a new accounting treatment will apply to new transactions only, for existing
transactions, the accounting treatment assigned when the transaction is validated, will be applied
throughout the life cycle of the transaction.
Financial Accounting - Suspense Processing to Report under Target

Accounts
Description:
Ability to report a Suspense movement under the target account (for SEC.TRADE only) if the suspense
movement is related to a customer or broker account.
Value Proposition:
Prior to R15, the Suspense processing was posted to an Internal account, which reflects under the
same reporting properties of the internal account .
From R15 , Suspense movements arising from the actual settlement is reported under the target
account of customer/broker.
Financial Accounting - Reporting of Third Party Balance

Description:
Ability to report the Receivable/Payable or the suspense movement arising from a SEC.TRADE
relating to a third party customer, who does not maintain an account in T24.
Value Proposition:
Previous to R15 , the settlement to the broker is done through the Nostro account, and the
settlement instructions are sent to the broker’s bank. In T24, for a Security Trade even if the broker
does not maintain an account in the system, it is still created as a customer record, but the broker
settlement is done against Nostro account.
Collateral - Collateral Allocation Logic

Description:
Provision to define priorities for allocation of multiple collaterals to single limit liabilities
Value Proposition:
Prior to R15 , when one limit liability is covered by multiple collaterals, the default allocation happens
in the alpha-numeric order of Asset-CIF id. There is no option for the user to define any order in
which this allocation happens
Collateral - Online Collateral Valuation

Description:
Facility to have all the collateral exposure reports or enquiries to show the correct value of the
underlying portfolio asset.
Value Proposition:
Previously Portfolio Collaterals used to get the latest value of the portfolio only when , the LIMIT or
COLLATERAL or COLLATERAL.RIGHT is amended.
From R15, a new field REALTIME.ALLOC is added to the versions of COLLATERAL.PARAMETER with
which it can be decided whether Portfolio Collateral revaluation has to happen online or COB or
online at a specific interval.
Delivery - Change of CARRIER in DE.CUSTOMER.PREFERENCES

Description:
Provision to remove obsolete carrier information
Value Proposition:
Previously the application DE.CUSTOMER.PREFERENCES allowed users to choose and select whether
or not to send a message to a specified carrier within the message group.It is not possible to remove
a carrier from the group; this was done to allow a user to temporarily not use a carrier while
retaining the details, so that it can be reused in the future.
FATCA - FATCA Balance Aggregation

Description:
FATCA regulation requires Financial Institutions to consider aggregation of account balances for both
individuals and entities in certain circumstances. The accounts with balances less than $50000 for
individuals, and less than $250000 for entities, can be treated as non-US accounts and not be
subjected to any due diligence. Whereas, the high value accounts will be subject to enhanced due
diligence. The system is enabled to provide the relevant details to help institutions comply with this
regulation.
Value Proposition:
Previously T24 had the provision and framework to compute Aggregated Balances.
From R15 , System can calculate Aggregated balances of clients based on the Aggregation Parameter.
FATCA - FATCA Customer Relationship

Description:
Facilitates the bank to link the Joint Owner (JO)/ Beneficial Owner (BO)/ Substantial Owner (SO)
through FATCA.CUSTOMER.SUPPLEMENTARY.INFO (FCSI).
Value Proposition:
The previous functionality offered no feature to record the relationship of the primary customer of
the bank with the Joint Owner (JO)/ Beneficial Owner (BO)/ Substantial Owner (SO) in the
CUSTOMER.RELATIONSHIP application, which will be linked to the
FATCA.CUSTOMER.SUPPLEMENTARY.INFO (FCSI)
From R15 , Whenever new FCSI records are created for individual customers, those customers can be
linked through a record in the CUSTOMER.RELATIONSHIP application (with RELATIONSHIP.TYPE as
‘Tax’).
Further, this CUSTOMER.RELATIONSHIP record can be linked to any portfolio owned by any of the
customers, through the SEC.ACC.MASTER application. Whenever this is done, a new record gets
created in FATCA.CUSTOMER.SUPPLEMENTARY.INFO (FCSI) application with an ID similar to that of
the CUSTOMER.RELATIONSHIP record.
FATCA - FATCA Reporting

Description:
A participating FFI is obliged to report information required by the US Treasury with respect to
accounts treated as US accounts, maintained at any time during each calendar year, in the format
provided. FATCA Reporting in T24, deals with updating the account balance and valuation
information pertaining to US Accounts, into a base file, which can then be used for Reporting. The
system generates an XML file for Form 8966. Also, the UK HMRC reporting schema is now supported.
Value Proposition:
A new module called FATCA Reporting (FE- ) has been introduced. A new parameter record called
FATCA.REPORTING.PARAMETER is used, to determine the accounts, which need to be included in the
Report. On the reporting date, a Close of Business process updates all details pertaining to a
customer including the Aggregate Balances to the FATCA.TAX.BASE file.
The base file has data like client name, address, TIN, ownership details and account balances.
From this base file, the users can extract any report that is required for reporting to the IRS or the
local regulator.
Form 8966 XML Report
Users can generate an XML file from T24, as per the schema provided for filing the Form 8966. A UK
specific XML report can also be generated by setting the HMRC field in
FATCA.REPORTING.PARAMETER record for UK specific users to generate the XML as per HMRC
schema.
To generate this XML, the user must update a FATCA.XML.REQUEST record. On authorising this, the
system creates a "workfile". Then the FATCA.BASE.XML.GENERATION service selects the work file
and generates the XML record.
IFRS - Securities Impairment

Description:
Provision to specify the Allocation amount for a specific contract.
Value Proposition:
Prior to R15 , In T24 IFRS.DATA.CAPTURE supported the impairment accounting for the following
applications:
LD.LOANS.AND.DEPOSTIS
MM.MONEY.MARKET
SL.LOANS
AA.ARRANGEMENT.ARCHITECTURE
From R15 , In order to allow Securities to use the IFRS Impairment, a new option
SC.TRADING.POSITION is added to the field APPLICATION in IFRS.DATA.CAPTURE.
IFRS.DATA.CAPTURE :This application captures the information related to impaired contracts or

groups, or information related to re-classification and existing contracts moving into IFRS.
Field: APPLICATION : This field accepts the application for which the Impairment details have to be
updated and accepts a valid T24 application name supported by IFRS.
Currently AA.ARRANGEMENT, AZ.ACCOUNT, LD.LOANS.AND.DEPOSITS, MM.MONEY.MARKET &

SL.LOANS are supported.
System Tables - Ability to Use a Local Routine for Certain Types of

Amortization Calculation
Description:
Additional amortisation options are provided for core generic accrual and amortisation processing in
order to:
1) calculate the daily amortization amount using a local routine
2) post the P&L entry to an internal account
3) set a calculation start date
Value Proposition:
Previously T24 provided generic functionality to handle the straight line accrual or amortisation of
fixed amounts for a fixed time period. It will generate the relevant accounting entries and had the
functionality to handle changes to amounts and dates and to generate accounting entries.
From R15 , the application EB.ACCRUAL.PARAM is enhanced to allow the ability to use a local routine
for certain types of amortization calculation, for example, Rule of 78 and have the ability to post this
to a Suspense account rather than to P&L, and set a specific start date for the calculation, allowing
for grace periods to be defined.
The field AMORT.API has been added to EB.ACCRUAL.PARAM which is used to attach a local API
routine to a specific accrual calculation.
The EB.ACCRUAL application has been enhanced to record the following information that is passed
from the local routine defined in the field AMORT.API in the underlying EB.ACRRUAL.PARAM record,
and which is used by the system either to calculate or post the accrual.
The fields CR.ACCOUNT,CALC.START.DATE have been introduced in EB.ACCRUAL to aid this

fucntionality
Process Workflow - Creating local reference for generating ID

Description:
Local references for the PROCESS.ID and TASK.ID are created to populate the ID in the application
Value Proposition:
The PW module is enhanced to display the PROCESS.ID and TASK.ID local ref in the applications.
PW.UPDATE.PROCESS.ID.LREF and PW.UPDATE.TASK.ID.LREF are used to populate the ID’s in the
application . This functionality is only for BPM and they do not affect Process Workflow (PW)
Integration Framework - Schema defining the batch of event XMLs

Description:
Feature to provide standard schema structure for batch events
Value Proposition:
Previously, the batching mechanism does not support any standard schema for transformation of
event batch xml on the individual event XML documents as the batch does not preserve the
integration flow schema definitions.
Integration Framework - Batch schemas for batched events

Description:
An option to monitor previous transaction values as well

Value Proposition:
In R15 , if the MSG.DELIVERY.MODE is set to BATCH.EVENT.TYPE or BATCH.EVENT.TYPE.SORTED and

the 'Include Before Image’ selected while designing the flow then the values in the OLD.EVENT.XML
are delivered to the queue along with the EVENT.DATA.The previous transaction values can be
monitored.
Integration Framework - Intra-day Archiving of Delivered Events

Description:
The delivered events can be archived or deleted within the same transaction in which the event has
been delivered.
Value Proposition:
Previously, Integration Framework events were neither deleted nor archived after event delivery.
Hence the IF.EVENTS.INTERFACE.TABLE increased in size that led to few performance issues.
Treasury - Forward Rate Agreement - SWIFT 2014 changes- MT 340

Message
Description:
Swift MT 340 Message generation in T24 is enabled as per Swift 2014 changes.
Value Proposition:
Previous Functionality
Floating Rate Option code used in Tag 14 F of MT 340 message was in line with the Swift standards
prior to 2014 changes.
New Functionality
Provision to define the Floating Rate Option code in MARKET.RATE.TEXT application vide field
RATE.TEXT has been created. While populating the delivery related details, system populates User
defined Floating Rate Option code in MT 340 message. Should the Floating Rate Option code be
‘OTHER’, SWIFT Standards expect the User to provide additional information in Tag 72 of MT 340
Message. T24 is enabled to auto default the additional information which includes a code word. The
code word must also be defined in MARKET.RATE.TEXT file and in SWIFT.CODE.WORDS as well.Swift
MT 340 Message generation in T24 is enabled as per the Swift 2014 changes
Treasury - Interest Rate Swap - SWIFT 2014 Changes- MT 360 and MT

361 Messages
Description:
Swift MT 360 and 361 Message generation in T24 is enabled as per Swift 2014 changes.
Value Proposition:
Floating Rate Option code used in Tag 14 F of MT 360 and MT 361 messages was in line with the
Swift standards prior to 2014 changes.
New Functionality
Provision to define the Floating Rate Option code in MARKET.RATE.TEXT application vide field
RATE.TEXT has been created. While populating the delivery related details, system populates user
defined Floating Rate Option code in MT 340 message. Should the Floating Rate Option code be
OTHER, SWIFT Standards expect the user to provide additional information in Tag 72 of MT 360 and
MT 361 Messages. T24 is enabled to auto default the additional information which includes a code
word. The code word must also be defined in MARKET.RATE.TEXT file and in SWIFT.CODE.WORDS as
well.Swift MT 360 and 361 Message generation in T24 is enabled as per the Swift 2014 changes.
Treasury - Forex - NDF to Generate MT300

Description:
MT 300 for NDF deal confirmation and Rate fixing confirmation is now available in T24.
Value Proposition:
Previously , MT 300 for NDF deal confirmation and Rate fixing confirmation was not supported.
As per the new functionality , NDF is enabled to generate MT 300 on the following instances:
1) Deal Confirmation
2) Amendment to deal confirmation
3) Deal Cancellation
4) Rate Fixing confirmation
5) SWIFT.COMMON.REF field is added in ND.DEAL template and REVERSE.ACTIV.CODE in

ND.PARAMETER.
Core - Module Upgrade

Description:
Module Upgrade upgrades an individual module or product from a major release to another release.
The remaining modules within T24 remain in the original release
Value Proposition:
Prior to R15, when an upgrade is initiated all the modules installed in the system are upgraded.
From R15 a new facility is introduced to perform a Module specific upgrade. In this way, a partial
upgrade is possible which is done at the Module level.The user is now able to upgrade with the same
activities but limits the scope to the specific module only
Core - Enquiry for $RO tables

Description:
A new query is now available for $RO files (similar to $ARC files) in the T24 core Enquiry module.
Value Proposition:
Previously , there was no provision to query the history/read-only data (after introducing DL product)
separately from T24 Enquiry.
From R15 the newly introduced functionality are as follows:
1) An option to suffix $HIS$RO/$RO, as part of FILENAME field in the ENQUIRY application is

provided.
2) A validation for $HIS$RO and $RO suffix is introduced.
3) An option to drill-down and view the record by linking it to the application is added.
Security - Data Anonymisation - EB.ENC.PARAMETER

Description:
The EB.ENC.PARAMETER table is now enhanced to support all T24 tables including application and
non-application files which has an entry FILE.CONTROL
Value Proposition:
Prior to R15 the existing Data Anonymisation functionality depends on configuration in the
EB.ENC.PARAMETER table to identify what data is to be encrypted and the routines that are to
perform the encryption. The table must have a field specifying the applications that are to contain
encrypted fields and which will accept only valid T24 Application names.
From R15 , the EB.ENC.PARAMETER table is enhanced to include all sort of T24 tables including
Applications and Non Application. To minimize mismanagement of this table, additional checks are
enforced to allow core T24 tables other than valid Applications using the ENCRYPT.APPL field.
Security - Browser - Authentication using ADFS and SAML

Description:
Introduced a feature to enable SSO authentication using SAML and ADFS which also supports
authentication with federated identity
Value Proposition:
In earlier releases there was no mechanism in T24 and its interfaces, to communicate securely with
systems hosted outside the bank’s network.
From R15 , SAML and ADFS enables web-based authentication and authorisation scenarios including
cross-domain Single Sign-On (SSO), this helps in reducing administrative overhead of distributing
multiple authentication tokens to the user.
Accounts - Statement Processing

Description:
This facilitates trigger statement generation
Value Proposition:
Previously , the performance of reasonable volumes of printed statements through delivery was
found to be too inefficient for many production environments
From R15 this enhancement facilitates trigger statement generation and provisions for the following
are available:
1) Statement Service for all accounts (including HVT accounts) - New Background Service
2) Distribution of entries per account across agents using ‘Segment’ technique - Selection of entries
3) Consolidated Entries
4) Segment Size
5) Merging of Handoff from multiple segments into one before SWIFT formatting
Accounting Unit - EB Company Change for ACU DBU

Description:
Provision to move accounts and contracts from one accounting company to another
Value Proposition:
Prior to R15 , It was not possible to move accounts or contracts from one accounting company to
another
From R15, this functionality allows the bank to move accounts and contracts from one accounting
company to another, as long as it does not contradict the accounting rules configured for each
accounting company
Accounting Unit - Data Capture Changes for ACU DBU

Description:
Provision to allow mixed batches of accounting entries for Data Capture and AC.INWARD.FILE in AU
set up
Value Proposition:
Previously in an ACU DBU setup Data Capture batches are currently restricted to a single accounting
company; all entries in a batch must be allocated to either the ACU or DBU accounting company.
Collateral - Loan Trade Receivables

Description:
Provision to specify the Allocation amount for a specific contract
Value Proposition:
Previously T24 process was split to Collateral Allocation contract wise and stored in
EB.CONTRACT.BALANCES .
Now from R15 onwards Collateral application is enhanced to allow COLLATERAL.RIGHT to specify
Allocation amount. Two new fields ALLOCATION.CCY and ALLOCATION.AMT are added to related
versions of COLLATERAL.RIGHT application
Collateral - Change the COLLATERAL.RIGHT and COLLATERAL IDs

Description:
Facility to increase the maximum number of COLLATERAL.RIGHT records per customer from 99 to
9999
Value Proposition:
Prior to R15 , the COLLATERAL.RIGHT application allowed a sequence number of two digits only .
From R15 , COLLATERAL.RIGHT application was increased to include a four digits sequence number
instead of two digits. This increased the maximum number of COLLATERAL.RIGHT records per
customer from 99 to 9999
Customer - Enhancing the CR.PROFILE

Description:
It provides the opening up of the CUSTOMER Profile fields namely the CR.PROFILE and
CR.PROFILE.TYPE fields for inputting or holding values, in order to override the calculated or
uploaded values
Value Proposition:
Prior to R15 , CUSTOMER table provides a pair of multi value fields to allow the customer base to be
segmented (profiled). Multiple profile types can also be defined (i.e. profitability, loyalty, lifestyle, life
stage so on) and within each of these profile types, specific profiles (segments) can be created. For
example, within the profile type of 'life stage’, a bank may set up profiles for students, newly
employed, married, married with kids, kids in college, empty nesters, retired and so on. At present,
the process of assigning the profile to each profile type is done automatically through the
PW.TRANSITION
From R15 , Banks are now being able to update automatically, a customer’s profile for a specific
profile type, based on the CR.CUSTOMER.INTELLIGENCE data. It should also manually overwrite this
data if required, to allow users the discretion to change a customer’s profile. In order to facilitate the
following, changes are required in the CUSTOMER profile field.
A new set of fields are provided open to input or to hold, so that the calculated or uploaded values
can be overridden by user input.
The way in which each CR.PROFILE type is to be updated (rules or upload) needs to be specified in
order, to prevent uploaded data from being overridden by the specification of a rule.
Customer - Differentiating External Users from Banks' Customers

Description:
This enhancement helps banks to differentiate external users from the banks' actual customers,
when linked to the mandates processing in T24
Value Proposition:
Prior to R15 , T24 had a functionality to differentiate between the bank’s actual customers and the
prospective customers and not the external customers created for the sake of Internet Banking
purposes.
Delivery - SWIFT 2014 Maintenance Changes

Description:
Swift has changed the usage rules for MTn92 TAG 79. This change in T24 allows clients to have
amended swift usage rules on sending MTn92 messages, when /FRAD/ (the code used when request
for cancellation is sent due to a fraudulent payment) is used in TAG 79. The system thereby
populates the mandatory fields from the original message onto the outgoing MTn92 message.
Value Proposition:
Prior to R15 , MTn92 was generated from EB.QUERRIES.ANSWERS application. If the field
ORG.MSG.NARR was blank, T24 populated the original message field.
New Functionality
In order to the support the change from Swift for TAG79, the field ORG.MSG.NARR in
EB.QUERRIES.ANSWERS application is amended so that when /FRAD/ is entered, the system
populates the mandatory fields from the original message into the outgoing MTn92 message.
Interest and Charges - Interest Waiver

Description:
The new development allows minimum waive amount along with the specific currency in the interest
definition tables such as GROUP.CREDIT.INT / ACCOUNT.CREDIT.INT. It also allows calculation with
history rate, if there is any currency rate change, for any back-dated transactions or interest
corrections.
Value Proposition:
T24 currently had the option to set the Minimum Interest Waive Amount and Interest Waive Rules,
which checked the rounded total interest for each interest type against a minimum amount in the
currency of the Interest.
Limits - Single Credit Line Group Limits

Description:
The new development facilitates the utilization of a Group Limit when different customers have
different Limit Serial Numbers.
Value Proposition:
Previously Similar to Individual limits, shared limits can also be defined for Multiple Credit lines
(Serial Nos. 01 up to 99). The shared limit that matched the serial number given at the product level
was utilised for the transaction, if the individual limit was not sufficient to cover the Liability. This
limits the utilisation of other limit products (with different serial numbers) linked to the sharing
group.
From R15 ,Single Credit Line Group Limits allow utilisation of group limits even when the product line
serial number does not match with that defined at the contract level. Instead of having multiple
credit lines defined for a group limit, group credit line can be created with a single product serial
number. This single credit line group limit will be utilised by the contract even when the serial
number defined at the contract level does not match with the group limit's serial number.
Limits - Allow AA Balance to be Checked by Limit

Description:
Provision to define Balance types that can be excluded from Limit check and Limit update.
Value Proposition:
Currently AA module currently involves credit check and utilization in the following ways:
Credit check for interest and charge related transaction
Availability on the limit amount will consider the interest and charges
Limits of reducing type will be updated for interest and charge transactions
The credit check and utilization will happen for both online and close of business transactions. The
arrangement limit will be impacted when an activity involving a balance type is defined as “STMT”.
From R15 , The new field EXCLUDE.CR.CHECK is added in AC.BALANCE.TYPE. This setup decides
whether the Interest charges is to be excluded for limits or not.
Data Framework - Enquiry for $DIM files

Description:
A new query is now available for $DIM files (similar to $RO files) in the T24 core Enquiry module.
Value Proposition:
Previously, there was no provision to query the Dimensional data separately from T24 Enquiry.
From R15 , user will be able to query the data moved to Dimension instance from T24 Enquiry similar
to $RO files.
Funds Transfer - Generation of FT Prior to Frequency Date

Description:
Funds transfer can be generated a few days prior to the credit value, in order to initiate the clearing
process.
Value Proposition:
Previous to R15 , The standing order application accepts a date and frequency based on which, the
payments were made on the account. During COB/SOD of the processing date, the Funds transfer is
generated and payment is made if the transaction is successful.
Funds Transfer - Non STP Function for FT Creation

Description:
Provision to define the version, which can be used for generating the Funds Transfer transaction
during the processing of the Standing Order.
Value Proposition:
Currently, any FT generated for the STOs are created by writing the values of the STO in the FT table,
by which the user can have no control on the FT created. FT is created by the system automatically
and the user can only provide the override approval for the Pending FT. Hence, there is no ability to
attach a version to the FT that is generated, and perform the customisation possible with an online
transaction
In R15 , bank can define the version, which can be used for generating the Funds Transfer transaction
during the processing of the Standing Order. It is also possible to put the Funds Transfer on hold with
Zero Amounts so that the user may take it up for further processing to action the payments.
Funds Transfer - MT101 Netting Agreement

Description:
Facility to hold agreements between receiving bank, sending institution and ordering customer which
serves the incoming/outgoing SWIFT messages.
Value Proposition:
Previously , before processing an incoming MT101 message agreement the details must be checked
by the sender of the message and the ordering customer.
From R15 , the agreement between Account Servicing Financial institution and Ordering Customer;
and the agreement between Sending Financial Institution and Ordering Customer, serves incoming
and outgoing MT101 SWIFT message
AML - Support for Private Wealth

Description:
Security Transfer Transactions can now be screened via AML. The screening is done online using
product VL (AML Screen)
Value Proposition:
Prior to R15 , VL (AML Screen) only supported screening of customer and Funds Transfer
transactions.
From now onwards A transaction key in via SECURITY.TRANSFER can be screened by AML. Any
version of the SECURITY.TRANSFER transfer application can be used to capture security transfer data
and can send it to AML for screening.
Funds Transfer - Generation of FT Prior to Frequency Date

Description:
Funds transfer can be generated a few days prior to the credit value, in order to initiate the clearing
process.
Value Proposition:
Previous to R15 , The standing order application accepts a date and frequency based on which, the
payments were made on the account. During COB/SOD of the processing date, the Funds transfer is
generated and payment is made if the transaction is successful.

NIB_Technical_Changes

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_Technical_Changes

Uploaded by

Copyright:

Available Formats

NIB Upgrade Assessment - Technical Changes from R10 to R15

New field LOGIN.STATUS has been introduced to check the login

Repeated Crashes at System level detected by tSM

Crashes at .LOAD/.SELECT stops the service. Repeated Crashes on the

Repeated Crashes at System level detected by tSM

EB.DICTIONARY enhancement to support the MB Translation

Easy to switch between different Languages using simple set up

Enhancement in R11 of BANKING FRAMEWORK

Enhance EB.DICTIONARY, VERSION and ENQUIRY to support Model Bank Translation

2) Enhance the Language table in T24 to support up-to 99 Languages

EB.DICTIONARY enhancement to support the MB Translation

Easy to switch between different Languages using simple set up

Duration of the activity can be defined now in Hours as well as

Enhancement in R11 of BANKING FRAMEWORK

Duration of the activity can be defined now in Hours as well as minutes.

Revisit already executed activities without the condition.

Enhancement in R11 of BANKING FRAMEWORK

This functionality definition can be disabled by setting NO to field USE.WORKFLOW.PATTERNS in

This functionality definition can be disabled by setting NO to field USE.WORKFLOW.PATTERNS in

Recursion helps the process to execute a particular activity n number

This functionality definition can be disabled by setting NO to field USE.WORKFLOW.PATTERNS in

Executing two or more activity in parallel within a process definition.

Executing one activity from the list of activities based on a condition.

Configuring T24 Services

Only Available for service control set as STOP

Caching across Multiple Transactions

Ability to process multiple messages/Applications in a single Transaction.

In prior releases Database operations were not cached across transactions.

Caching in R11 significantly Reduces interactions to hardware resources by 40%.

For AA transactions Facility available for usage with OFS.GLOBUS.MANAGER

Caching available as default for all bulk transactions.

Browser Performance Improvement

TEC COB Enhancements

TEC Profiles T24 Activities

Overhead in TEC is avoided New METRICs are available.

Transaction Bulking in T24

Can be used for local jobs and can be easily parameterized.

Bulking records in COB

Traditional Cache Availability

Record routines to return filtering ability of jobs

Ability of the job is updated at PGM.FILE.

Removal of Unnecessary locks

Jobs that do ‘nothing’ finishes real fast.

Locking Overhead on core tables F.BATCH.STATUS/F.LOCKING/F.BATCH/ F.JOB.TIMES has been

JobList Records distributed towards the end of job

However switching on OP.CONSOLE is recommended only on test environments as it occupies more

To identify performance of a particular application/transaction OP.CONSOLE can be enabled in SPF

Enhanced TSA.STATUS table

Enquiry to verify USER login status

New Enquiry to list Active Users(USER.STATUS)

Promoted columns are being created to improve the performance of

A time constraint can be set for executing a SQL query which is

This Enhancement bypasses the Justification of the attributes if

ARC Mobile - M-Commerce Application on XHTML

XHTMLPayment’ Channel is made available now

ARC Mobile - T24 Push Schema to ARC Mobile

In R12, T24 PUSH Schema to ARC mobile is available

Replacement of DE.MT942.GENERATE phantom to service

The current DE.MT942.GENERATE phantom is replaced with a service to make it multi-threaded,

Multiple PV Management records

A category can only be specified in one PV.MANAGEMENT record.

Option premiums denominated in any currency for FX OTC options

Prior to R12, the premium can be denominated in contract currency only.

Swap Maturing on a Non-working Day