R12 Functional Highlights

R12 Release Highlights Summary
This document is a high level overview of the enhancements that have been delivered in R12.
R12 Release Highlights Summary- Release R12.00 -Page 2 of 18 - (c) Temenos Systems 2012
Application Framework R12 Summary
The following is a high level summary of the Application Framework enhancements delivered in R12 .
A DDA service is provided for T24 that can be consumed by an external system
From R12 it is possible to consume an external DDA system from T24 products. Transactions can be put on hold until the external system
responds with the approval message. This can be achieved using force dispo.
Logging
From R12 it is possible to maintain a centralised log repository and record all contents into it. This centralised log file will be used everywhere
for reporting purposes or for debugging purposes. The log repository is moved from T24 level to the TAFC layer. The log directory can grow in
size and can be purged when required.
T-Verify
TVerify has been enhanced from R12 it is possible to;
l To terminate or continue with the upload process based on the severity of the error
l Capture transactions that comes in through the NS module of T24.
l TV.UPLOAD.FOR.PLAY is now run as a service in T24.
T24 PCI-DSS Compliance

This SI does not represent new functionality but measures current functionality against the PCI-DSS standard.
Password Management
SHA-256 will now be default Encryption algorithm used for T24 passwords From R12 onwards.
A key factor in the SHA encryption is that it uses an encryption practise called Salt, in basic terms instead of having your seven character pass-
word being changed to a seven character encryption a salt will introduce random characters in to the encrypted output to make it longer e.g.
twenty characters long
ARC-IB support for transaction confirmation using out of band SMS

From R12 Transaction confirmation using out of band SMS allows one-time passwords (OTP) to be delivered by SMS text messaging or Email
using STMP securely identifying a user via two factor authentication .
Banking Framework
The following is a high level summary of the Banking Framework enhancements delivered in R12.
Retail Sweeping
The existing account sweeping functionality has been packaged into its own module. The new module code is RS.
The EB.COMPONENT and EB,SYSTEM.ID records are released for RS
To support AA 2 new fields have been added to AC.ACCOUNT.LINK
l FROM.ACCT.BAL.TYPE
l TO.ACCT.BAL.TYPE
The @id to the AC.ACCOUNT.SWEEP.HIST file records is now appended with either SW for Sweeps and PO for Pooling. to differentiate
between the records raised in this file by these modules.
Pooling
The existing pooling functionality has been packaged into its own module. The new module code is PO
The EB.COMPONENT and EB,SYSTEM.ID records are released for PO
Two new batch records are released
l ACSW.START.OF.DAY.SWEEP for Retail Sweeping

l ACSW.START.OF.DAY.POOL for Corporate Pooling
The batch ACSW.START.OF.DAY is now obsolete
The @id to the AC.ACCOUNT.SWEEP.HIST file records is now appended with either PO for Pooling and SW for Sweeps . to differentiate
between the records raised in this file by these modules.
Interest and Charges

It is now possible to suppress the calculation of tax on interest correction amounts until the next capitalisation date. The field
TAX.CORR.CAP has been introduced to the application ACCT.GROUP.CONDITION. if this field is set to Yes then the tax calculation in the
interest adjustment will not happen until the next capitalisation date.
The application IC.CORRECTION.DETAILS has been introduced to hold the details of the adjustments. The following new fields have been
added the applications ACCR.ACCT.XX; STMT.ACCT.XX and INFO.ACCT.XX.
High Volume Accounts

To provide a solution for high volume accounts where only one account is maintained in the system rather than multiple sub accounts.
From R12 a new process is introduced for High Volume accounts. The field HVT.FLAG is introduced into the account record, if this field is set
to Yes, then this account is marked as a high volume account and will use the high volume account processing. This can be set on customer,
nostro and Internal accounts. It is currently not possible to use this on AA accounts.
Move Account Balances to EB.CONTRACT.BALANCES

To standardise the account balance updates so that they are held in the EB.CONTRACT.BALANCES record rather than the account record and
improve the number of record locks on an account. Combined with the high volume processing enhancement it reduces the number accounts
required by the system.
PV Calculation - Secured and Unsecured Collateral

There is a requirement to calculate provisioning balances based on the secured or unsecured portion of the balances. From R12 it is possible to
apply a different percentage to a Secured or Unsecured portion of the balance used to calculate provisioning. The percentages to be applied to
the calculation are entered in the fields STD.PERCENT and SEC.PERCENT in the PV.PROFILE record
PV Multiple PV Management records

There is a requirement to allow different provisioning classifications and rules to different products. From R12 the PV.MANAGEMENT appli-
cation has been enhanced to allow multiple PV.MANAGEMENT records. This will allow the bank to set up classification and calculation rules
per product. In the following example records have been created for LD Commercial Loans and LD Personal Loans
Remove Suspense Account from AA Pay and Receive

Pre R12, additional internal suspense entries are raised for AA contracts, these entries can have an impact on reconciliation and performance.
From R12 the entries to the internal suspense account have been removed for AA Loans and Deposits.The system will now process these
entries to the new AC.BALANCE.TYPE AASUSPENSE. By removing these additional set of accounting entries raised over the AA Internal Sus-
pense account it will improve reconciliation and performance
Statement entries Masking in AA

Pre R12, customers found the account statements produced for AA accounts confusing and complex to understand. Additional entries are
raised that are internal to the AA module, these are currently shown in the statements.
From R12, the client will now able to mask statement entries raised by AA and soft accounting as required from statement printing and
enquiries. This will enable the bank to produce client statements that are relevant for the client.
User Defined Statement Narratives for AA

From R12 users will be able to enter narratives into the AA.ARRANGEMENT.ACTIVITY records directly. These will then be used by the sys-
tem to update the accounting entries, dependant on the configuration in the relevant AC.POSTING.DETAILS records. This will enable the nar-
ratives printed in the Account Statements to be more user friendly.
Build link to unauthorised entries for accounts

From R12 the EB.CONTRACT.BALANCES file holds unauthorised Credit and Debit balances in separate fields. There are also separate sets of
fields to hold Forward and real unauthorised balances. This will enable the storing the unauthorised entries from transactions for an account
and will benefit the client by:
l Help in Account closure validation when closing an Account that has unauthorised transactions.
l To properly rebuild an Available funds ladder if unauthorised transactions exist for an Account.
l The ability to produce a report and enquiry to show the list of unauthorised entries for an Account
Demand Deposit Account

It has been identified in the market that Banks no longer want to replace all of their systems at once but are preferring to implement parts of
systems. This means that they are able to replace individual components with external ones.
With the enhancements to the DDA functionality in R12, a bank will now be able to decide to either install T24 in one of the following ways;
l Master DDA, where non T24 systems can integrate to T24 DDA
or
l T24 applications consuming an external DDA. They will be able to continue to use their existing DDA.
This functionality has been developed to work with the Retail Accounts module (AR) within the Arrangement Architecture Framework.
Wherever accounts have been created using AR, this feature can be used.
Corporate R12 Highlevel Summary
The following is a high level summary of the Corporate enhancements delivered in R12 .
Syndicated Lending – Interest Capitalisation

Within the Syndicated Loans (SL) module the option is now available for full or partial capitalisation of interest on SL.LOANS contract as well
as the ability to define multiple margins on a loan contract. The enhancement allows interest to be capitalised back in the loan and the loan
amount is increased.
l New fields have been provided and initially SL.PARAMETER must be set to accommodate the “Rolled-up interest” related P&L entries.
l New fields are present within FACILITY. The rates defined at facility level will be automatically populated at SL.LOANS level once the
capitalisation flag is set to YES in SL.LOANS.
Spreads defined at the FACILITY level will be inherited at loan level and a user can amend the rates if required within SL.LOANS. Whenever a
new contract is input the user has to decide if capitalisation is required for this contract or not; if required then CAPITALISATION flag needs
to set to YES. Additional new fields have been provided within SL.LOANS to support the new functionality.
Other tables which have been enhanced to support this development are SL.LOAN.BALANCES and SL.LOAN.PART.BALANCES.
Syndicated Lending: Tranche Level Repayment Schedules

Within the Syndicated Loans (SL) module the option is now available to define repayment schedules at tranche level. Repayment of the tranche
will effect repayments on all the SL.LOANS drawn under the particular tranche.
l Cascades to loan level

l Amendment to the schedules will only affect new loans under the facility
l Annuity Repayment schedules are also allowed
The table FACILITY.REPAY.SCHEDULES will now allow repayment at tranche Level and the new live file SL.REPAY.SCHEDS now holds all
the repayment dates and amounts which need to be adjusted upon repayment based on the repayment schedule.
Online Repayment is possible by way of the Service FACI.TR.ONLINE.REPAY.
It is possible to input multiple payments under the same Tranche on the same day.
It is also now possible to input a single currency repayment against the outstanding loan amounts of differing currencies. The actual amount
repaid must equal the currency of the facility.
Miscellaneous Deals - Ability to extend MD expiry date for END type contracts
This enhancement will enable the users to extend the expiry date for contracts where commission is processed at the end of the commission
period.
The contract extension can be processed on or before the maturity date.
It is possible to extend the MD expiry date and ability to define a new commission period and collect the new commission when CSN.PA-
YMENT.TYPE is equal to “END” and AUTO.EXPIRY equal to “NO” , on or before the expiry date.
There is also an option available to the users to increase or decrease the principal amount with effective dates.
Miscellaneous Deals: Ability to extend MD expiry date for BEGIN type contracts
This enhancement will enable the users to extend the expiry date for contracts where commission is processed at the start of the commission
period.
The contract extension can be processed on or before the maturity date.
It is possible to extend the MD expiry date and ability to define a new commission period and collect the new commission when CSN.PA-
YMENT.TYPE is equal to “BEGIN” and AUTO.EXPIRY equal to “NO” , on or before the expiry date.
There is also an option available to the users to increase or decrease the principal amount.
Syndicated Lending: Stand Alone guarantee joins SL Facility

This functionality provides the ability to add an already issued guarantee to an existing syndicated agreement using the SL module.
This functionality will provide the ability to add an existing Guarantee/Standby Letter of Credit to an existing SL facility by entering the new
“SL Tranche Ref” within the relevant screen version.
Once a record is committed, the system will change the existing LIMIT.REF value and pick up the existing SL LIMIT.REF (by using the
SL.TRANCHE.REF field).
During authorisation the system will perform the necessary limit updates as per standard T24 functionality.
Syndicated Lending: Syndicated Letters Of Credit

This functionality provides the ability to process both Import and Export Letters of Credit under a syndicated facility.
This functionality will provide the ability to process both Import and Export Letters of credit under an SL facility agreement. The Letters of
credit will still be managed within the LETTER.OF CREDIT module but the management of the Syndicated facility will be managed by the SL
module.
For LC's syndication means that the LC liability amount will be syndicated in exactly the same manner as s syndicated Loan amount would be.
i.e.. the amount of the LC liability will be divided up among the Lead Bank and a number of participants. In this case the lead bank will be the
Issuing Bank or Confirming Bank and each of the participants will share a portion of the LC liability.
LC commissions and fees will still be handled by the LC module, however certain commissions may be shared with the syndicate; these will be
flagged within LC / DRAWINGS and processed automatically through SL.CHARGE.
MD – Backdated Online Closure

This functionality provides the bank with the option to mature an MD with a back valued date.
MD – Principal Movement and Rate Change with Option to Return Commission

This functionality provides the bank with the option to return commission or not in case of a principal movement or commission rate change
New fields have been introduced in MD.PARAMETER and MD.DEAL. These fields help the user to
l Input a new CSN.RATE

l Input an effective rate for the CSN.RATE
l Opt for returning the excess commission collected due to negative principal movements or decrease in CSN.RATE
For the following types of contract change:
l Principal Movement
l Rate Change
l Combined Rate Change and Principal Movement
Database R12 Highlevel Summary
The following is a high level summary of the Database enhancements delivered in R12.
Compression of TJ Log Records

From R12 onwards, 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.
The TJ log compression is enabled automatically when TJ is switched on. The threshold limit beyond which the records are compressed is set
using the command ‘jlogadmin –Znn‘, where nn is threshold in bytes. The default threshold is 300 bytes. The compression can be switched off
by the command ‘jlogadmin –Z0’
Enable or Disable Record Update Path in TransendFrom

R12 onwards, an 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.
jBASE Detailed Scaling

This enhancement will help the client to increase the performance of the system, especially with UNIX Operating system. 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. Shared memory table
is an area in memory where the details of locks like pid, inode number, device number, time stamp are stored. The position of each lock in the
table is identified with the help of a hashing algorithm.
TJ log - Network compression

From R12 onwards, an option is provided in jlogdup to compress the TJ WRITE records which are transferred to a backup server / hot standby
server. This functionality works in conjunction with the TJ log compression functionality. Any TJ WRITES of size below the threshold set
using the ‘-Z’ option are taken by the TJ Network compression function and compressed before they are transferred to a backup / hot standby
server. This will reduce the network transfer time of the TJ logs.
Payments R12 Highlevel Summary
The following is a high level summary of the Payments enhancements delivered in R12 .
Replacement of Phantoms
Pre R12 the Phantom processing was single threaded and would lead to frequent locking contentions and performance problems.
The Payments related phantoms have been replaced with standard T24 Service process in R12.. With the Phantom processing moving to stand-
ard T24 Service process the process becomes multi-threaded, scalable with performance gains.
SWIFT 2011 changes

The field ORD.CUST.ACCT in FUNDS.TRANSFER application has been introduced to include account number for tag 50A and 50K in MT103
and MT102 messages. Again the PAYMENT.DETAILS field in FUNDS.TRANSFER application has been enhanced to accept a standard Creditor
reference value which gets updated in Tag 70 of SWIFT messages, for Straight through processing
STP Message enhancement as a service to Delivery

This enhancement will provide the framework for STP (Straight Through Processing) support for delivery messages generated by T24
From R12, the delivery messages needing STP processing are routed through the Integration Framework to “Repair” the message for it to be
STP compliant through external processing software. This enables the messages to be processed in T24 without human intervention thereby
speeding up the settlement process and avoiding errors..
PWM R12 Highlevel Summary
The following is a high level summary of the PWMenhancements delivered in R12.
Trade Confirmation and settlement Message Aggregation (SI 19262)

From R12 it is possible to handle aggregated trade confirmation message (MT 515). The aggregated messages will be processed and if there is a
match, the trades would be authorized else the error log will be updated with the variance for the users to correct. Similarly, the settlement
instruction messages will also be aggregated. The settlement confirmation message received as a response will be reconciled with individual
pending settlements and settlements authorized.
The following enhancements have been done in T24 for addressing the above requirement and also for addressing certain other issues with
regard to Straight Through Processing.
1. Handling aggregated confirmation of purchase or sale received from the broker/executing party and reconciling the same with the client
advice of executions (MT 513) received from the broker/executing party. Once the reconciliation is done, the underlying trades will be author-
ized.
T24 will then send aggregated settlement instruction (MT 541, MT 543) to the custodian. Once the settlement status (MT 548) and con-
firmation (MT 545 or MT 547) is received from the custodian, they will be disaggregated and reconciled with the underlying trades before updat-
ing the settlement status/processing settlement for individual trades.
2. MT 514 message is used to advice the broker/executing party regarding allocation of bulk trade. T24 always generates an allocation instruc-
tion if the message type is configured in SP.STP.PARAM. The generation of MT 514 will be made more flexible (with controls at broker
level/transaction level) to cater to non-block trades and also for situations where the bank wants to handle allocations separately.
3. Handling MT 515 messages (confirmation) received without a preceding MT 513. T24 assumes that a MT 513 is always received and MT 514
is always sent. At present, T24 cannot process a MT 515 received without the underlying MT 513 and MT 514 messages. This is to handle
cases where orders/executions are processed outside of T24 and T24 processing starts only from client confirmation (MT 515) stage. In this
case, based on the MT 515 received, the underlying trade(s) have to be authorized.
4. Flexibility in generation of MT 502 – at present, if MT 502 message generation is activated, all orders are considered to be STP orders. The
MT 502 generation will now be made more flexible with controls at broker/order level.
IFRS Reclassification
From R12 it is possible to reclassify securities in line with IAS 39 IAS 39 requires that, at inception, a non-derivative financial asset is classified
into one of the following categories:
l fair value through profit and loss

l loans and receivables
l held-to-maturity; or
l available-for-sale.
Currency Volatility Margins

From R12 it is possible to possible to specify margin rates depending on the currency of the asset to factor in current volatility. The current
enhancement is to introduce currency volatility margins. The new functionality will calculate margin value by deriving currency wise margin
rate. Currency wise margin rate can be setup in the following files;
l ASSET.TYPE
l SUB.ASSET.TYPE
l ASSET.BY.CATEG
Customer response to the margin call by means of cash transfer or Security transfer will be used to cover up the margin call. In that case, Trans-
action codes of cash and Security transfers will be considered as a Flow.
Partial Redemptions
In R11, partial redemptions are not supported directly.
From R12 the field, REDEM.PERCENT has been added to DIARY. The redemption percentage can be specified in this field. If 50% of the hold-
ings are to be redeemed, the user will input a value of 50 in this field. Based on the redemption percentage specified in this field, RETAIN.NO-
MINAL Field will automatically be updated in all the resultant entitlements. As a result, only 50% of the qualifying holding will be redeemed
and remaining will be retained. Partial Redemptions are now supported.
Diversified Margins- Lombard Lending

T24 is now enhanced to cover diversified margins. The salient features of the enhancement are:
a. Identifying portfolios eligible for availing diversified margins – Diversification has to be ‘activated’. By simply complying with the diver-
sification criteria, portfolio will not be eligible for diversified margins
b. Identification of diversified portfolio or diversified position based on:
1. Number of stocks (eligible/non-restricted/all) held in the portfolio;
2. Holding caps on individual stocks – Diversified LVRs, if, for example, no stock is more than 25% of the client’s port-
folio
Group Portfolio – Reporting

Wealth reporting can also be used to generate reports for a group of portfolios apart from the reports generated for single portfolios. Grouping
of portfolio can be done using the T24 Asset Management features and functions. Consolidated reports can be generated for all the portfolios
that belong to a group.
Advanced Alerts
From R12 it is possible to subscribe to more new alerts and these alerts can be subscribed by Clients and Relationship managers. The alerts
that can be subscribed only by clients/relationship managers have been classified in T24 MB versions accordingly
MIFID (SI 178525 )

From R12 it is possible to comply with the MIFID requirements. MIFID consists of a client questionnaire that helps the bank analyze the risk
profile of the customer.
MIFID questionnaire consists of three different sections they are;
1. Questions related to client’s financial details

2. Questions that analyse the client’s level of knowledge on various financial products
3. Questions related to contributions and withdrawals
We also classify the products to various risk levels. After performing the risk profiling of the client we would be able to identify the types of
products that are suitable for the client and the ones that are unsuitable.
AM.BUILD.MODEL service for Dynamic Modelling

From R12, The automation of verification is made configurable via a field available on the Root Node of the AM.DYNAMIC.MODEL.
AM.DYNAMIC.MODEL.SERVICE validates hierarchy
AM.MODEL.BUY.SELL.SERVICE proposes Security Transfers to align Model Portfolio with the Dynamic Model structure
Input/Authorise the proposed Security Transfers
Verify AM.BUILD.MODEL record to create/rebuild Asset Allocation
The following considerations should be taken into account
l The automation of verification is made configurable via a field available on the Root Node of the AM.DYNAMIC.MODEL
l In the case of creating a new Dynamic Model, the id of the AM.DYNAMIC.MODEL will be applied to the new AM.BUILD.MODEL Id
and the associated Axis and Matrix field on the record (some sort of validation/reporting may be required in case the
AM.BUILD.MODEL id has been used already?)
l In the case of updating an existing Dynamic Model, the id of the AM.DYNAMIC.MODEL will be used to verify the existing
AM.BUILD.MODEL record with the same Id – with the 'Rebuild Existing' field set to ‘Yes’
Retail R12 Highlevel Summary
The following is a high level summary of the Retail enhancements delivered in R12.
API Prevalidation
Pre R12 in AA, the defaulting of fields is done by defining a default value in the product condition. This functionality, however does not provide
for any “conditional defaulting” either in the core or through local development.
A new field PRE.VALIDATE.RTN is added to ACTIVITY.API Property, which would carry all the existing characteristics of a VALIDATE.RTN
– like stating routines at the Activity class/Activity levels and inheritance during publishing. The API stated in the PRE.VALIDATE.RTN would
be called before the core Property Validation. In this way, user can populate/modify the fields which can input and get the system ready for
core validation.
Bonus Processing
Pre R12 in AA, Bonus Processing and to age the expected bills is not available.
From R12 it is possible to:
l Trigger Bonus through ACTIVITY.RESTRICTION Product condition. Activity based rules can be triggered during maturity of the
arrangement or Property based rules can periodically grant BONUS
l Three Periodic Attribute Classes i.e. Number of overdues; Average amount and Number of days will handle different BONUS con-
ditions and return the result
l In OVERDUE Property class Field BILL.TYPE is used for defining individual Overdue status. This Field can have multiple bill type
aging definitions defined.
l BILL.TYPE is soft coded so that aging rules may be defined based on AA.PAYMENT.TYPE
l Credit charge property used to pay a charge, e.g. Bonus
New Interest Basis - E1

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.
Passbook for Arrangements

Through this enhancement Passbook printing has been enabled for AA accounts.
RFO R12 Highlevel Summary
The following is a high level summary of the Retail Front Office enhancements delivered in R12.
ARC Mobile Customer Registration via ARC IB
From R12 it is possible to register a customer for Mobile Banking via ARC IB.
ARC Mobile Web Service for Customer Registration and Control

With the introduction of this functionality the clients would be able to register customers for Mobile Banking via T24.
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"
Configuring Multiple Instances of T24
ARC Mobile Configuration with two T24 instances

In order to configure the same instance of the ARC Mobile to connect with two (or more) instances of T24 changes have to be applied to
deploy the following components:
l Database
l Context.xml
l TCserver.xml
l Internal application
With the introduction of this functionality the clients would be able to have multiple concurrent connections with two (or more) separate
instances of T24
Incoming SMPP
With the introduction of this functionality the clients would be able to receive incoming SMPP messages.
Maintenance Mode
The functionality details the requirement to be able to put all the mobile channels into maintenance mode. During Maintenance mode any
requests from a customer will be met with a response that indicates that the ARC Mobile software cannot process their request as the system
is undergoing maintenance.
The ARC Mobile System or a part of back end infrastructure may undergo maintenance. During such maintenance, the infrastructure from the
external network to the ARC Mobile services is still functional. But some connectivity from the ARC Mobile System to the back end systems
may not be available. During such time the customer must receive a message that indicates the service is currently not available, via the channel
using which the customer is interacting with the ARC Mobile System at the time of the request.
MCommerce Application on Smart Phones

A flexible MCommerce application is built on Android, iPhone and Windows Phone 7 devices. The functionality is identical to the existing
J2ME MCommerce application, but is designed to have the look and feel of the respective devices.
MCommerce Application on XHTML

With the introduction of this functionality the clients would be able to do MCommerce via XHTML channel.
mCommerce Plug-ins for Model Bank Functions
The new functionality allows the client to avail more plug-ins of the Model Bank Functions. The Client can also configure their own Model
Bank functions.
Multi-Byte Data Storage

Multi-Byte Data Storage is now made available. ARC-Mobile can employ several different types of relational database system. The ARC Mobile
business logic is purely in Java and all Java code is multi-byte (Unicode) compliant . The mapping from Java objects to relational tables/col-
umns is portable. However some relational database systems require specific configurations and definitions to support multi-byte characters.
New Privileges
Blocking/Unblocking of a Customer Channel
Separate privileges have been created to block/unblock a customer channel. Each of these privileges can be assigned to two different users or
the same user so that access to block/unblock can be restricted.
Push T24 Schema to ARC Mobile

With the introduction of this functionality the clients would be able to map the schema from T24 to ARC Mobile.
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".
WP7 MBanking UI Revision

Main Menus in WP7
In the WP7 the main menus have been re-structured as follows – My Accounts, Recent, My Service. The sync information would be appearing
only on clicking the info button instead of displaying it in every page. The UI appearance has been changed.
With the introduction of this functionality the clients would be able to have a better UI standard for WP7.
SOA R12 Highlevel Summary
The following is a high level summary of the SOA enhancements delivered in R12.
Secure Document Transfer

TOCF-EE is now able to upload documents / images to a database or centralised document repository. Blob data type should be used for stor-
ing documents on the database. Application server’s datasource mapping should be used for managed database connection. Database column
names should be configurable.
Integration Framework
Pre R12 T24, as such does not have a mechanism to send out notifications to an external system. Integration Framework answers to this
requirement to send out notifications to an external system.
From R12 the Integration of T24 with other external systems enables notifications sent out from T24. Hence if a 3rd party system needs T24
data, then the 3 rd party system can get it seamlessly. This Integration is been implemented through standard practices with a framework of
loosely coupled components.
Integration Studio
With the Integration Framework, it is now possible to send out notifications to a third party system. Integration Studio is used by the System
Integrator to define when the notification has to be sent out and what information has to be the part of notification.
Integration Studio is the design time tooling where
1. The VERSION / Components that can trigger event out can be specified
2. Define Integration Events and flow
3. Create enrichment instructions
4. Store Integration project including events and flows into SCM
5. Publish the project to T24. Integration Framework / Flow Catalog will validate the enrichment instructions with the service
repository to check the designer passed it a valid enrichment instruction.
6. Get xml schema (xsd) that describes format of event out.
Integration Studio is available as Visual Studio and Eclipse plug-in. To install integration studio the minimal requirement is:
Eclipse 3.5 for Eclipse Plug-in.
Visual Studio 2010, .NET Framework 4.0 for Visual Studio Plug-in.
From R12, it is possible to use the Integration Studio to define the event and the flow, that will be used by the Integration Framework to emit
notifications.
TWS Composer (.NET)
PW Support in TWS (.NET)

OFSFunction class now supports additional fields for PW requirements, such that a new activity could be attached to that version in user’s
work list.
Strong Data type in TWS (.NET)

From R12 onwards it is possible to create web services that support strong datatype, thus reducing the work of data type validation at T24
level.
When a new TWS .NET project created, the option (Data Typed WSDL) could be selected in the Log On screen. This option generates data
typed schema for the Versions and Enquires added to the project. These Data Types are to be identified based on the definition of T24 Data
types for the respective fields in Standard Selection in T24. Also, restrictions are to be provided for the respective fields as defined for them in
the Standard Selection in T24.
Support for WS-Security in TWS (.NET)

From R12, it is possible to send the user credentials with the SOAP header, instead of SOAP body, so that anonymous calls, security breach,
unauthenticated users are not allowed to access the T24 System via TWS interface.
WS-Security (Web Services Security, short WSS) is a flexible and feature-rich extension to SOAP to apply security to web services. Even if the
web service relies upon transport layer security, it is required for the service to know about the end user to construct OFS. A WSS-header is
used to convey the end user's token, eventually making TWS WS-Security compliant.
When a new a TWS .NET project is created, the option “User Credentials in Message Header” could be selected in the Log On screen. This gen-
erates TWS .NET project with WS-Security enabled
TWSComposer (EE)
PW Support in TWS (Java)

From R12 it is possible to insert a new activity attached to the version in user's worklist using TWS (EE). OFSFunction class now supports
additional fields for PW requirements.
Strong Data Type

From R12, onwards it is possible to create web services that support strong datatype, thus reducing the work of data type validation at T24
level.
When a new TWS Java project created, the option “WSDL with Strong Datatypes” could be selected in the Log On screen. This option gen-
erates data typed schema for the Versions and Enquires added to the project. These Data Types are to be identified based on the definition of
T24 Data types for the respective fields in Standard Selection in T24. Also, restrictions are to be provided for the respective fields as defined for
them in the Standard Selection in T24
Support for WS-Security in TWS (Java)

WS-Security (Web Services Security, short WSS) is a flexible and feature-rich extension to SOAP to apply security to web services. Even if the
web service relies upon transport layer security, it is required for the service to know about the end user to construct OFS. A WSS-header is
used to convey the end user's token, eventually making TWS WS-Security compliant.
Web Service Interoperability Technologies (WSIT) is part of sun metro which implements several new web services technologies including WS-
Security, WS-Trust, WS-SecureConversation. TWS uses WSIT for its security implementation.
From R12, it is possible to send the user credentials with the SOAP header, instead of SOAP body, so that anonymous calls, security breach,
unauthenticated users are not allowed to access the T24 System via TWS interface.
Treasury R12 Highlevel Summary
The following is a high level summary of the Treasury enhancements delivered in R12.
Handling premiums in any currency for FX OTC Options trades

The premium for FX OTC options contracts can be denominated in any currency irrespective of the contract currency. The currency in which
the premium needs to be collected and the details can be input in DX.TRADE.
DX to update PM Files
PM reports will reflect the bank’s exposure to interest rates and currencies arising from trades in financial futures. This functionality is limited
to Exchange Traded financial futures contracts done for the bank’s own dealer book.
Whenever an ‘event’ occurs (for example: contract initiation, amendment, closeout, etc.), the impact will be reflected in the PM files. . All
‘hedge’ transactions are update the PM files, but ‘trade’ type transactions may also be included to update PM files on parameterization.
You would now be able to see the CAS, GAP and FXP positions getting updated by Interest rate, Bond and Currency futures.
A new table, PM.DX.PARAMETER is introduced to enable update of position files through PM.TRAN.ACTIVITY and PM.DLY.POSN.CLASS.
Interest rate Swap maturing on a non-working day

Through the current Enhancement, the Day Convention ‘Following ‘and also in case of Modified Following, where the holiday is not on a month
end, the Accounting Entries and Delivery Messages related to IP, PX and Charges will start reflecting the next business day as Value Date
although the Contract maturity process remains same as existing. Of course, the Swap Schedules and Swap Balances too will capture the next
Business day as value date.
However, the Date Adjustment ‘Period’ will be treated same as ‘Value’ in all such cases.
A new field MAT.PAYMENT.DATE is introduced in SWAP.PARAMETER table and the same provides an option to the User if the Accounting
Entries and Delivery messages need to reflect the next business day as arrived by the day convention ‘Following’

R12 Functional Highlights

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

R12 Functional Highlights

Uploaded by

Copyright:

Available Formats

R12 Release Highlights Summary

T24 PCI-DSS Compliance

ARC-IB support for transaction confirmation using out of band SMS

The EB.COMPONENT and EB,SYSTEM.ID records are released for RS

To support AA 2 new fields have been added to AC.ACCOUNT.LINK

The EB.COMPONENT and EB,SYSTEM.ID records are released for PO

Two new batch records are released

l ACSW.START.OF.DAY.SWEEP for Retail Sweeping

The batch ACSW.START.OF.DAY is now obsolete

Interest and Charges

High Volume Accounts

Move Account Balances to EB.CONTRACT.BALANCES

PV Calculation - Secured and Unsecured Collateral

PV Multiple PV Management records

Remove Suspense Account from AA Pay and Receive

Statement entries Masking in AA

User Defined Statement Narratives for AA

Build link to unauthorised entries for accounts

Demand Deposit Account

Syndicated Lending – Interest Capitalisation

Syndicated Lending: Tranche Level Repayment Schedules

l Cascades to loan level

Online Repayment is possible by way of the Service FACI.TR.ONLINE.REPAY.

The contract extension can be processed on or before the maturity date.

The contract extension can be processed on or before the maturity date.

Syndicated Lending: Stand Alone guarantee joins SL Facility

Syndicated Lending: Syndicated Letters Of Credit

MD – Backdated Online Closure

MD – Principal Movement and Rate Change with Option to Return Commission

l Input a new CSN.RATE

For the following types of contract change:

Compression of TJ Log Records

Enable or Disable Record Update Path in TransendFrom

jBASE Detailed Scaling

TJ log - Network compression

SWIFT 2011 changes

STP Message enhancement as a service to Delivery

The following is a high level summary of the PWMenhancements delivered in R12.

Trade Confirmation and settlement Message Aggregation (SI 19262)

l fair value through profit and loss

Currency Volatility Margins

Diversified Margins- Lombard Lending

Group Portfolio – Reporting

MIFID (SI 178525 )

MIFID questionnaire consists of three different sections they are;

1. Questions related to client’s financial details

AM.BUILD.MODEL service for Dynamic Modelling

AM.DYNAMIC.MODEL.SERVICE validates hierarchy

Input/Authorise the proposed Security Transfers

Verify AM.BUILD.MODEL record to create/rebuild Asset Allocation

The following considerations should be taken into account

From R12 it is possible to:

New Interest Basis - E1

Passbook for Arrangements

ARC Mobile Customer Registration via ARC IB

ARC Mobile Web Service for Customer Registration and Control

Configuring Multiple Instances of T24

ARC Mobile Configuration with two T24 instances

MCommerce Application on Smart Phones

MCommerce Application on XHTML

Multi-Byte Data Storage

Push T24 Schema to ARC Mobile

WP7 MBanking UI Revision

Secure Document Transfer