core banking - data migration strategy_banking

Core Banking Software - Data Migration Basic Methodology and Approach

Authors

Anantharam Srinivasan Lead Consultant - Banking Practice

&

Abhishek Kashyap Senior Consultant - Banking Practice

iGATE Global Solutions Limited

158-162 (P) & 165 (P) -170 (P) EPIP Phase II

Whitefield Bangalore -560066, INDIA

Core Banking Software Data Migration Strategy

iGATE Global Solutions LTD of 23

TABLE OF CONTENTS

INTRODUCTION................................................................................................................................................... 4

PURPOSE & BACKGROUND .................................................................................................................................... 4 INTENDED AUDIENCE ............................................................................................................................................ 4 THE SCOPE............................................................................................................................................................. 4

OVERVIEW OF CONVERSION.......................................................................................................................... 5

CONVERSION ACTIVITIES CYCLE........................................................................................................................... 5 Pre-conversion Activities .................................................................................................................................. 5

Global Data Set-up ........................................................................................................................................ 5 Data Clean up ................................................................................................................................................ 6

Post-conversion Activities ................................................................................................................................. 6 DATA VALIDATION ................................................................................................................................................ 6 DATA EXTRACTION AND LOADING........................................................................................................................ 6

Activity-Flow in Conversion.............................................................................................................................. 7 GENERAL ASSUMPTIONS/GUIDELINES FOR DATA MIGRATION................................................................................ 7

PRE-REQUISITES OF CONVERSION............................................................................................................... 8

STATIC DATA SET-UP ............................................................................................................................................ 8

DATA MIGRATION FOR RETAIL MODULE................................................................................................ 10

DATA MAPPING .................................................................................................................................................... 10 CUSTOMER INFORMATION DATA ......................................................................................................................... 10

Assumptions..................................................................................................................................................... 10 Procedure ........................................................................................................................................................ 10

MODULE - SAVINGS ACCOUNTS.......................................................................................................................... 11 Assumptions..................................................................................................................................................... 11 Prerequisites.................................................................................................................................................... 11

MODULE - CURRENT ACCOUNTS......................................................................................................................... 11 Assumptions..................................................................................................................................................... 11 Prerequisites.................................................................................................................................................... 12

MODULE - OVER DRAFT ACCOUNTS................................................................................................................... 12 Assumptions..................................................................................................................................................... 12 Prerequisites.................................................................................................................................................... 12

MODULE - TERM DEPOSITS.................................................................................................................................. 12 Assumptions..................................................................................................................................................... 12 Prerequisites.................................................................................................................................................... 13

MODULE - LOANS................................................................................................................................................ 13 Assumptions..................................................................................................................................................... 13 Prerequisites.................................................................................................................................................... 13

MODULE - CHECK BOOK ..................................................................................................................................... 13 Assumptions..................................................................................................................................................... 13

MODULE - STOP PAYMENT UPLOAD.................................................................................................................... 14 Assumptions..................................................................................................................................................... 14 Procedure ........................................................................................................................................................ 14

MODULE - STANDING INSTRUCTIONS.................................................................................................................. 14 Assumptions..................................................................................................................................................... 14

MODULE - LIEN UPLOAD ..................................................................................................................................... 14



Assumptions..................................................................................................................................................... 14 MODULE – DEMAND DRAFTS UPLOAD................................................................................................................. 14

Assumptions..................................................................................................................................................... 14 MODULE - OUTWARD CLEARING......................................................................................................................... 15

Assumptions..................................................................................................................................................... 15 MODULE - INWARD CLEARING ............................................................................................................................ 15

Assumptions..................................................................................................................................................... 15

DATA MIGRATION FOR CORPORATE MODULE ..................................................................................... 15

APPROACH, BASIC UPLOAD AND ASSUMPTIONS................................................................................................. 15 Data Upload to CBS and Customisation in Upload utility ............................................................................. 16

REQUISITE COVERAGE OF TABLES IN CONVERSION............................................................................................ 16 CONSIDERATION AND RESTRICTIONS. ................................................................................................................. 16

Collaterals.................................................................................................................................................... 17 General Ledger............................................................................................................................................ 17 Corporate Loans ..........................................................................................................................................17 Money Market .............................................................................................................................................19 Foreign Exchange........................................................................................................................................ 20 Letters Of Credit.......................................................................................................................................... 20 Bills and Collections ................................................................................................................................... 21 Securities Contract ......................................................................................................................................22 Fixed Asset Management ............................................................................................................................ 23

CONCLUDING REMARKS................................................................................................................................ 23



Introduction

Purpose & Background The purpose of this document is to provide some fundamental understanding on Data Migration activities to be undertaken during the Core Banking Software (CBS) Implementation at a Bank. This includes the details of planning and finalizing the approach for converting data from existing system(s) of the bank into the CBS system. This document describes the activities involved in conversion, pre-requisites of conversion, the methodology to be followed, the module-wise strategy for converting the data and the post-conversion activities that would to be performed.

Intended Audience This document is intended for the senior management of the bank, who will be taking strategic decisions about data conversion, Information Technology Group personnel of the bank and others involved in data conversion process along with the CBS implementation team.

The Scope The scope of this document covers following module’s data in terms of conversion in CBS systems:

Retail module which includes the following functionalities � Customer Information Data � Savings Account � Current Account � Overdraft � Term Deposits � Loans � Check Book � Stop Payment � Lien � Standing Instructions � Demand Draft � Outward Clearing � Inward Clearing Corporate module which includes the following functionalities � Corporate Loans � General Ledger Balances � Letters of Credit � Bills and Collections � Foreign Exchange � Money Market � Limits and collateral



� Nostro Reconciliation � Fixed asset management � Securities and derivative

It essentially covers following aspects:

� Identification of activities for data conversion � Identification of roles & responsibilities for conversion Preparation of an ideal stage for mapping of data fields in existing systems to CBS and approach for automatic conversion of data from existing system � Pre-conversion activities � Post-conversion activities � Post-conversion testing/consistency checks

Overview of Conversion All information required for CBS system to work might not be directly available in existing system(s). All information available in the existing system(s) may not be directly usable in CBS. Also it is possible that, differences may exist in the manner of processing the data in the existing system and the way it will be handled in CBS. The extent of differences in the available data and the data required for CBS to work will dictate whether the information from the existing system can be used directly in CBS and / or it has to be modified / processed before loading into CBS or data needs to be manually entered in CBS. Basic purpose of conversion study is to identify mapping of fields from existing system(s) of the bank to fields in CBS, primarily for automatic conversion of data and to decide the scope and the extent of manual data maintenance that needs to be done for data conversion purpose. Once the mapping study is complete, the actual data conversion process comprises of three main steps as follows:

� Pre-conversion Activities � Data Extraction & Loading in CBS � Post-conversion Activities

The details of these activities are discussed in detail at later stages of the document.

Conversion Activities Cycle Conversion activities can be divided into three main categories as described below:

Pre-conversion Activities Before converting data from the bank’s existing system into CBS either automatically or manually, there are certain activities that need to be completed as pre-requisites related to setting up bank-wide data for CBS and cleaning up existing data. These activities would be identified during the course of the data mapping discussions with the Banks migration team.

Global Data Set-up

Setting up bank-wide static global data and module-wise and product related set up is a pre-requisite for automatic conversion programs to work. These Global Data setup would be created



by the bank is a specific database. The access to the setup schema will be tightly controlled and the data will be extracted from this scheme prior to every mock conversion.

Data Clean up

All the requirements of bringing the source data in the desired, synchronised and integrated form (which reaches to a convertible stage) would have to be dealt by data cleaning up exercise in consultation with iGATE team. Data conversion activities should ensure that the existing data inconsistencies should be brought to a common functional requirement of the CBS application upon conversion. Missing or incorrect data must be rectified before conversion. Taking into consideration the design and customization changes, CBS conversion will specify the unique keys (set of fields that make a record unique) for each table. The bank will have to ensure that there are no duplicates on these keys. Mock conversion runs would give indication about possible data clean up that needs to be taken up before actual data conversion run.

Post-conversion Activities The data that could not be converted due to reasons like unavailability in the extraction file or due to erroneous source values needs to be manually maintained as a post-conversion activity. This can be done using CBS data maintenance options. Other operationally important details can also be maintained manually through CBS maintenance. The data which is defaulted by the conversion programs due to non-availability in the old system might also be needed to be enriched and modified later on for any corrections. CBS data maintenance options can be used for this purpose also. The CBS vendor and the Bank’s migration team need to take a decision on manual conversion of a few records based on the volume / number of records.

Data Validation Data validation is an important component of data migration and adequate safeguards have to be built in to ensure that the exact status of the system before and after the migration is captured. This can be accomplished by using reports to compare data migrated. Validation methodologies, which can be used, are:

� The bank will identify the critical data elements for each module. After the Upload in new system, the data will be extracted in required format from new system. Data in the same format is extracted from the existing system and compared.

� The critical data from the earlier system is compared procedurally using new system standards.

Data Extraction and Loading Data required for automatic conversion for each module to be discussed and separate documents for each of the modules would be agreed and signed off for that purpose in consultation with the Bank team. Such a document would enlist the field to field details in CBS modules, their mappings with the existing system fields, and corresponding action on each of them.



The Migration team to extract the data from the existing systems on the day of conversion and will provide data in Database temporary table.

Activity-Flow in Conversion The detailed sub-activities, along with the responsibility matrix, to be undertaken during conversion to CBS are discussed in the “Pre-Requisites of Conversion” section.

General assumptions/guidelines for data migration The following assumptions / guidelines are required for the upload formats:

� For all numeric fields which contain amounts / balances, if the balance is negative, the first character would carry ‘-‘sign or Dr/Cr as required by the new system.

� All the date fields will be provided as per CBS specified format � Percentages will be denoted as per CBS specified format � All closed accounts will not be migrated � Transaction history will be migrated only for loan accounts. For other types of accounts

only the Cutover Date Balances will be migrated � For interest calculation the interest accrual figure & last accrual date provided by Bank will

be uploaded, so that new system can take care of interest calculation after migration by considering the accrual amount and date

� All the Static codes like Country code, City code etc. in current system needs to be mapped with the new system codes.

� For certain fields’ if data is currently not available as is required by new system, such fields will populated with some pre-defined default values by the bank. Bank to provide a list of the fields which are not present in old system and present it to business and operation for finalization of the value.

� All other modules, which are not covered in this document, shall be treated separately on case to case basis.

� Account numbers in new system should be migrated as per the new system with one to one mapping with respect to old system.

Any change in setup which will have impact on migration has to be reviewed and then applied.



Pre-Requisites of Conversion The data organization in CBS is such that the static data / set-up data needs to be set-up before conversion. On the day of conversion, an automatic conversion will be done to load the data from flat files into CBS. After that the data that could not be converted automatically but needs to be set-up before CBS operation begins, has to be entered using CBS maintenance option. This section gives module-wise details of all these activities.

Static Data Set-up The list of Static Maintenance tables in CBS is provided below:

The data for following tables will be provided by the bank either from the old existing system or by collation of information from the manually documented registers etc. as on the date of conversion and populated in CBS. Some of these data would be migrated to the set-up schema containing the other set-up entities CORE

Entity Description Mode of conversion

Remarks Responsibility

SMS Bank level parameters maintenance

Security management parameter setup

upload Bank IT

User Role Maintenance Creation of user role Manual setup Operation

User Profile maintenance

Creation of user profile Manual setup Operation

Currency holidays Currency holiday calendar

Manual setup Operation

Local Holidays Local holiday calendar Manual setup For head office manual creation, remaining branches upload using PL/SQL

Operation/ iGATE

Bank parameters Bank parameter creation

upload Bank IT/Operation

Branch parameters Branch parameter creation

Manual setup For head office manual creation, remaining branches upload using PL/SQL

Operation/iGATE

System dates Application dates Static values iGATE

Customer category maintenance

Customer category maintenance


Messaging Parameters Messaging Parameters Manual setup Operation

Purge Maintenance Purge Maintenance Manual setup Operation

Overrides table Error codes details Static values iGATE

Country Country definition Auto upload Upload from Treasury iGATE

Currency Currency definition Auto upload Upload from Treasury iGATE

Currency pair Currency pair Auto upload Upload from Treasury iGATE

Currency rate type Currency rate type Auto upload Upload from Treasury iGATE

Currency rates Currency rates Setup Operation



Amount Text Amount Text Static values iGATE

Customer, currency Settlement instructions

Customer, currency Settlement instructions

Upload iGATE/Bank IT

Product Groups Product Groups Manual setup Operation

Customer Account class Customer Account class


Limits template details Limits template details Manual setup Operation

Credit Limits Credit Limits Upload Bank to decide the limit line structure

Bank to get back

Collateral types Collateral types Manual setup Operation

Collateral details Collateral details Manual setup Bank to decide

GL Chart of Accounts GL Chart of Accounts upload Operation

Accounting period code maintenance

Accounting period code maintenance


Transaction code maintenance

Transaction code maintenance

Upload Operation

Account revaluation maintenance

Account revaluation maintenance


MIS classes and codes MIS classes and codes Manual setup Operation

Journal Entry Parameters

Journal Entry Parameters


Status codes maintenance

Status codes maintenance


Interbranch Parameters Interbranch Parameters


Messaging

Entity Description Mode of conversion

Remarks Responsibility

Advice Format Advice Format creation for all modules

Bank IT/iGATE

Customer Address Customer advice maintenance

Auto upload iGATE

BIC Code BIC code maintenance Upload All required BIC code will be taken from swift alliance. Only list banks which have key arrangement will be uploaded

iGATE/Bank upload



Data Migration for Retail Module

Data mapping Data elements of various upload files to be used for migrating modules from existing system to new system will be provided to the bank. The modules can be broadly divided into the following categories:

� General Ledger � Customer information File � Operative Accounts (Savings, Current, Cash Credit and Overdraft Accounts) � Term Deposit Accounts � Over Draft Accounts � Loans � Others

Customer Information Data

Assumptions The following details available in the existing system should match with new system

� During flat file generation from current system, new Customer Ids will be generated. This

file will be generated in upload format. � The mapping of the new customer number with the old number would be maintained in the

existing system. As part of migration, the old customer ID will also be stored in one of the field for future reference.

� Some customers existing as minors in the system might have become major, which may not be reflected in the current system. Such minor’s data should be cleaned up as a pre migration cleaning activity before taking it into new system.

� If employee’s details are not available in system then Bank can decide that all employee accounts will be migrated as normal customer accounts.

Procedure The following uploads will be used for customer information:

� During generation of data file for CIF, new customer Ids will be generated and the upload

file format will be tagged with the new Customer Id. A mapping table will be created in current system between the old Customer Identification number and new customer IDs. Henceforth the subsequent customer uploads and other account uploads will use the new customer Ids.



Module - Savings Accounts

Assumptions

� Only open accounts (Active, Inactive and dormant accounts) will be migrated into new system.

� The account numbers in new system should be the same as in the existing system. � Accounts needs to be populated with the GL details and product code as defined in new

system. � Accounts with frozen status etc. would be migrated with the same status. � Transaction history of accounts will not be migrated. Only the balance as on the day of

migration will be uploaded. This implies no historical account statement can be viewed/retrieved in new system for the transactions that have happened in existing system.

� For accounts with monthly average balance method of interest calculation, the daily balance between the 1st of the migration month and the day of migration will be uploaded. During credit interest application, new system should use this amount for the calculation of interest.

� The interest (Accrual) amount applicable between the last interest calculation date and month before actual migration will be required. New system will use this data during next interest application.

� Transactions value dated less than the migration date will not be allowed in new system after migrating to new system.

� Liens on accounts will be migrated as it is stored in the current system.

Pre-requisites

� Customer Information File (CIF) Upload to be completed before account uploads can take place

Module - Current Accounts

Assumptions

� Only open accounts (Active, Inactive and dormant accounts) will be migrated into new system.

� The account numbers in new system will be same as in the existing system. � Accounts needs to be populated with the GL details and product code as defined in new

system � Accounts with frozen status etc. would be migrated with the same status. � Transaction history of accounts will not be migrated. Only the balance as on the day of




� Interest Details from last interest application date till day before actual migration will be provided for migration. New system will use this data during next interest application.


� Liens on accounts will be migrated as it is stored in the current system.

Prerequisites

� CIF Upload to be completed before account uploads can take place

Module - Over Draft Accounts

Assumptions � Only open accounts (Active, Inactive and dormant accounts) will be migrated into new

system. � The account numbers in new system will be the same as in the existing system. � Accounts needs to be populated with the GL details and product code as defined in new

system. � Transaction history of accounts will not be migrated. Only the balance as on the day of



� Interest Details from last interest application date till date of migration will be provided for migration.

� Active Limits & Drawing power will be migrated � Check book issues details & Stop Check details will be migrated � Lien Marked and Frozen Account details should be migrated with same status. � Security Details will be migrated.

Prerequisites

� CIF Upload to be completed before account uploads can take place.

Module - Term Deposits

Assumptions

� Only open Term deposit accounts will be migrated into new system. � The account numbers will be same as existing contract numbers. � History of the Term Deposit Accounts will not be migrated. Only the current principal

balance as on the day of migration will be uploaded.



� Transactions in converted accounts, which are value dated less than the migration date, will not be allowed in new system after migrating to new system. But New Accounts value dated prior to date of migration to new system can be opened.

� Renewed Term Deposit Accounts will be migrated as if the account was opened on the last renewed date.

� There are few accounts which are set for auto renewal, but the renewal might have not happen. It has to be ensured that the accounts due for renewal before the migration date are renewed. So all the term deposit accounts will have maturity date greater than or equal to date of migration + 1.

� Interest accrued/booked from the date of account opening will be uploaded in new system. � The maturity amount calculated in existing system can be different from the maturity

amount calculated by new system. The tolerance limit for the difference in maturity amount is to be decided by the bank.

Prerequisites

� CIF Upload to have been completed

Module - Loans

Assumptions

� Only open Loan accounts will be migrated into new system. � All Regular and Past Due loans would get migrated in the state as they are. � Security details will be migrated. � Memo Pad, Loan Documents Details will be migrated. � Existing standing Orders for loan repayment will be migrated. � Bank will provide interest accrual figure till date of migration. � All the limit level data for loans will be captured and migrated.

Prerequisites

� CIF Upload to have been completed

Module - Check Book

Assumptions

� Check Book details will be uploaded in new system as available in the existing system. � Also the check leaf status would be migrated from the existing system



Module - Stop Payment Upload

Assumptions

� The details of check stopped will be uploaded for all the live accounts

Procedure

� Firstly all the Check Issued details will be uploaded � Then the stop payment check will be uploaded to new system

Module - Standing Instructions

Assumptions

� The Data will be migrated using Standing Instructions Format (SI). � Several child accounts may be linked to mother account and funds are transferred between

them in order to maintain MBR (minimum balance requirement) on either side. This will be supported by setting up two SIs for each set of accounts. So for each account set (Mother and one child account) two SIs will be uploaded i.e. first upload will be for the child account excess amount and second will be for child account in short amount

Module - Lien Upload

Assumptions

� The Lien details for Current, Savings, and Term Deposit accounts will be uploaded into new system with details

� Lien details for Savings, Current & Term Deposit accounts will be uploaded only after completion of basic account details and balance upload.

Module – Demand drafts upload

Assumptions

� All outstanding (issued and not paid) DD will be uploaded � All DD will be uploaded into the same GL



Module - Outward Clearing

Assumptions

� All the outward clearing outstanding check will be uploaded. By outstanding it means deposited but the result (acceptance or reject) has not come till EOD on date of migration.

Module - Inward Clearing

Assumptions

� All the checks accepted as a part of the cutover date’s inward clearing file will be reflected as a debit in the customer’s account

� After Migration, bank opens a zone for Inward clearing zone, dated the next working day and will do an upload of the all rejected instruments.

� On that day if the checks are funded, then it is not rejected and the accounts are debited for the same, and if the checks are rejected, then it is returned as a rejected check

� The inward zone is closed on same day afternoon, and the checks are returned

Data Migration for Corporate Module

Approach, Basic Upload and Assumptions

� The conversion ideally needs to be done after the end of day (EOD) in a branch. The balance as at EOD would be converted in CBS.

� Only the outstanding balance in Corporate Loans, Letters of Credit & Guarantees, Bills & Collections, Forex and Money Market and securities will be converted.

� Contract wise transaction history, or historical information like accrual details, contract

amendment details would not be converted to CBS from the existing system. Hence for the converted contracts transaction details for the period prior to conversion date will not be provided in CBS through any Inquiry option. The bank will have to use their existing system running in the backup to support such inquiries.

� Data pertaining to Expense processing, fixed asset management, derivatives & securities

will have to be captured manually in CBS on the migration date. Apart from this, following are some of the basic agreed conditions that need to be followed for Upload.

The Extraction would have to be provided in specified format.



The file would contain all the records for the table line by line. Within the record in a line, the various fields would have to be provided in the format as required and mentioned in the data-mapping document. All dates to be as per CBS specified format The value of the field must not exceed the maximum length as specified in the data mapping document. The data type of the values provided in the file must match with the data type of the corresponding field values in the data-mapping document.

Data Upload to CBS and Customisation in Upload utility The data of the present system need to be extracted in a pre specified format as required by the CBS conversion utilities and as agreed upon by iGATE conversion team and the Bank’s extraction team. The Conversion utilities would be modified and amended to suit the customisation requests laid by the Bank.

Requisite Coverage of Tables in Conversion Module-wise details of coverage of the tables are provided in this section. The detailed field-to-field mapping of each of the fields would be agreed and signed off by iGATE conversion team and Bank’s conversion teams. The data fields would consist of some of the mandatory fields. These mandatory fields would be provided to the bank in the form of an extraction file format. The extraction of these fields has to be done. These mandatory fields can be defined as the ones that are not only just storing the indexed values (database level mandatory) in the CBS tables but also the ones that carry meaningful values (mandatory for the running the conversion) for the composite completion of the conversion. These fields would have to be provided in the extract files in all circumstances. There could be some fields that are not directly available in the source database, however if these fields are under the definition of mandatory fields for conversion, the necessary default or extraction program would have to be worked out as a necessary pre-requisite for the conversion. Certain tables / fields that cannot be extracted from existing data but are critical for conversion program to run will be assigned default values after considering impact of such data set-up in terms of operations in CBS system which needs to be ratified by banks’ personnel. Following the finalization of the conversion tables the bank needs to confirm that all their existing operations are covered under CBS.

Consideration and Restrictions. The way the data is captured stored and processed in CBS and the way bank’s existing system stores it, is normally quite different. The features and functionality of the two systems are different and also the system architecture varies. Despite the best efforts to bridge this gap, during data migration activity, there still would be some restrictions in the data conversion exercise due to many factors like time and efforts involved. This section highlights some important limitations and necessary precautions that are to be taken, as a result of the data conversion exercise.



Collaterals

The data pertaining to Collaterals are not present in the existing system. Based on the nature of facility it is linked to, the collateral will have to be migrated to the corporate module or retail module. Limits conversion would be done immediately after CIF conversion. Limits conversion is semi automatic. i.e. partly manual and partly Auto. The Templates for the Limits facility should be completed before conversion starts. All unsecured facilities can be uploaded into the system directly, if the data is provided in the required format. All secured facilities involving Collateral conversion, Pool creation and subsequent linkage with facilities should be done manually.

General Ledger

� The final GL chart of accounts along with the exact numbering of each of the GLs would have to be finalised by the bank before the commencement of the mock conversion activity.

� All GL balances of the branch, which has a corresponding reflection in the accounts, sub ledgers and CBS contracts, are to be included in the GL extract file. For the GLs, which are mapped for more than one product, figures would have to be split according to the products with the product codes specified with all such GL records in the extract. This is to enable the tracking of account level balance Vs GL balances. Bank has to ensure that the GL balances and the balances provided at the account / contract level are balanced.

Handling of accrual entries – Account / Contract level accrual figures should match with the corresponding GL balances Generally historical data will not be converted, i.e. only GL balances as on the conversion date

will be migrated.

� Any changes to the chart of accounts will be done before the conversion activity begins.

It is recommended that a cross-reference of the GLs in the Old and the new systems should be maintained at the extraction side as a mapping. This includes the break-up of any GL balance product wise. This will be helpful in verification and reconciliation of balances GL-wise in both systems at the end of the conversion activity. General Ledger balances in the existing system should be balance at the Branch Level. This means that at the branch level, the total Debits and total Credits for real and contingent should match separately.

Corporate Loans

Generic point for loans conversion Only active loans that have not matured/outstanding would be converted. No transaction history would be converted. This includes Past Schedules, repayments and Interest Rate history. � Only the outstanding amount of the Loan will be taken into CBS.



� Since the penalty amount cannot be given as a separate component at the time of conversion,

the penalty amount is added to the acquired amount. So the acquired amount will be consisting

of normal accrued interest and the penalty interest as applicable.

� The Old Customer Number will be replaced by the new customer number and the old Customer

Account number will be replaced by the new CASA Account generated in CBS.

� No Accounting entries will be passed by CBS during conversion.

� MIS Details if need to be tracked for the converted Loans, should be made available for each

contract. Alternately, it can be let to default from the product.

� Original start date of the loan to be captured for reporting and reconciliation purpose.

� The original reference should be taken as user reference number.

RReegguullaarr CCoonnttrraaccttss -- bbeeaarriinngg–– FFiixxeedd aanndd FFllooaattiinngg RRaatteess Regular contracts are those on which there has been no default and no overdue amount payable as such. The Value date of the Loan should be the conversion date. Only the outstanding amount of the Loan will be taken into CBS. The accrued amount till the date of conversion will be taken as the acquired amount along with the Interest component. Credit Line details should be available for each of the loan contracts so that the same can be input along with the contracts.

RReegguullaarr oovveerrdduuee CCoonnttrraaccttss -- bbeeaarriinngg–– FFiixxeedd aanndd FFllooaattiinngg RRaatteess Regular overdue contracts are those, which do not have any schedules over due as such (Principal or Main Interest components) but have some past penalties as payable. The contracts shall be input in the same way as REGULAR Loans but with the ‘Acquired Interest’ field populated with the appropriate values for both to the ‘Penal Interest on Delayed Interest’ as well as the ‘Penal Interest on Delayed Principal’. Thus on the first payment date as per the schedule, the system would make these ‘Acquired Interest’ components also due along with the other regular schedule payments (of Interest and Principal). Irregular Loan contracts with overdue - fixed rate and floating rate Irregular contracts are those, which have at least one of the payment schedule component over due as such (Principal or Main Interest components). All such contracts will be uploaded into CBS with the value date as the last fully paid schedule date in the old system.

The principal amount will be the amount outstanding as at the last payment date. Care must be taken to ensure that the upload should have flag “pay past schedules flag as NO”.



All the payments made after this fully paid schedule date should be either entered manually or uploaded with the respective value dates of the individual payments. While making the manual payments, the Settlement Account is changed to the ‘Conversion GL’. Amortized Loans Regular Amortized Loans These contracts can also be uploaded in the same manner as Regular Bearing Interest Loan contracts. However the component for the schedule will be given as ‘Amortized’ rather than ‘Interest’ or ‘Principal’ as in the case of Regular Bearing Interest Loans. Principal is taken as the outstanding principal as of last payment date and value date is taken as last schedule date.

Future change in interest rate would lead to re-computation of repayment amounts. Care should be taken at the time of GL balances upload, the interest receivable & Interest income balance should not be taken. However if the GL balances cannot be separated then reverse the entry on a consolidated basis, at the product level. In case of Floating Rates for Amortized Contracts, the very first interest rate applicable for the contract in the old system – based on which the EMI was calculated originally should be given as the interest rate for CBS. This will ensure that the EMI calculated by CBS is the same as the EMI that is currently applicable for the contract in the old system.

IIrrrreegguullaarr AAmmoorrttiizzeedd LLooaannss All such contracts will be uploaded into CBS with the value date as the last fully paid schedule date in the old system. Maturity date will be given as the actual maturity date. The principal amount will be the amount outstanding as at the last payment date. Care must be taken to ensure that the upload should have flag “pay past schedules flag as NO”. All the payments made after this fully paid schedule date should be either entered manually or uploaded with the respective value dates of the individual payments. While making the manual payments, the Settlement Account is changed to the ‘Conversion GL’. Discounted and True Discounted Loans All such Contracts will be uploaded into CBS with the value date as the value date in the old system Care should be taken at the time of GL balances upload, the interest receivable & Interest income balance should not be taken. However if the GL balances cannot be separated then reverse the entry on a consolidated basis, at the product level. The other option is to consider the loan to be taken as Normal bearing loan with principal amount and interest rate as “Zero”, with the same maturity date. In this case interest income should be taken along with GL balances upload



Money Market

Money Market conversion would follow the same logic as that of Corporate Loans Module.

Foreign Exchange

SSppoott CCoonnttrraaccttss � All spot contracts maturing on or after conversion date will be converted into CBS. � All contracts will be input with the original booking date. � The messages should be suppressed for these contracts. � Charges to be waived at the time of conversion. � Settlement message to be suppressed at the time of conversion � The original reference should be taken as user reference number.

FFoorrwwaarrdd aanndd SSwwaapp CCoonnttrraaccttss � All spot contracts maturing on or after conversion date will be converted into CBS. � All contracts will be input with the original booking date, original spot date & original spot rate � The messages should be suppressed for these contracts. � Charges to be waived at the time of conversion. � Settlement message to be suppressed at the time of conversion � The original reference should be taken as user reference number.

FFXX RReevvaalluuaattiioonn � Revaluation in CBS is zero-based so, in the next EOD or based on the revaluation frequency in

CBS will take care of passing appropriate revaluation entries. � If the Bank follows Daily revaluation and as on the date of conversion, the previous days

revaluation entries will be reversed before the GL upload

Letters Of Credit

The type of Letters of Credit can be classified in following categories.

� Import Letters Of Credit � Export Letters of Credit � Guarantees � Shipping Guarantees

Letters of credit and guarantees would be uploaded into the system with the outstanding amount of the LC contract and original issue date. Only Live LC’s and Guarantees will be converted in CBS. All charges that are picked up during the Conversion upload would be waived. For amendment commission, calculation will be done only based on the outstanding amount. Adjustments, if any should be done manually. No availments will be captured.

NNoottee If there are any outstanding Bills under LC, these presentations will be captured as part of the Bills Data Upload. Changes will be made to the conversion program of CBS to disable the accounting entries for Availment of the LC through Bills module. The history of past information would be on the old system / records.



Non-Periodic / Flat Commission that has been collected in Advance would be waived.

Bills and Collections

CCoolllleeccttiioonn BBiillllss IInnccoommiinngg aanndd OOuuttggooiinngg

� All collection bills with bill amount greater than zero to be considered for conversion into CBS.

� The bill amount will be taken as the bill due amount as on conversion date. � All the other details should also reflect the current state of the Bill. � All charges that are picked up during the Conversion upload should be waived.

OOuuttggooiinngg PPuurrcchhaassee BBiillllss

� All outstanding purchase bills with expiry date on or after conversion date will be converted into CBS.

� The bill amount will be taken as the original bill amount at the time of purchase. � All the other details should reflect the current state of the Bill. � CBS will accrue interest from start date till conversion date - 1. � The balance in the interest accrual GL and equivalent balance in the income GL from the

old system will not be transferred to CBS. � If there are any partial payments done on these bills need to be manually done in CBS with

the date of liquidation as the original payment date.

IImmppoorrtt//EExxppoorrtt ---- AAcccceeppttaannccee//NNeeggoottiiaattiioonn BBiillllss uunnddeerr LLCC All outstanding acceptance bills under LC with expiry date on or after conversion date will be converted into CBS. � The bill amount will be taken as the bill due amount as on conversion date. � All the other details should also reflect the current state of the Bill. � System will be temporarily changed not to do LC availment for these bills since all LC’s will

be uploaded with current outstanding amount.

IImmppoorrtt PPaayymmeenntt BBiillllss uunnddeerr LLCC These bills need not be converted into CBS, as the bill payments would have already been made. Only new contracts will be input in CBS.

DDiissccoouunntteedd EExxppoorrtt BBiillllss bbootthh uunnddeerr LLCC aanndd nnoonn--LLCC

� All outstanding purchase bills with expiry date on or after conversion date will be converted into CBS.

� The bill amount will be taken as the original bill amount at the time of purchase. All the other details should reflect the current state of the Bill. � CBS will accrue interest from start date till conversion date - 1. � The balance in the interest accrual GL and equivalent balance in the income GL from the

old system will not be transferred to CBS. � For bills under LC, the system will be temporarily changed not to do LC availment for these

bills since all LC’s will be uploaded with current outstanding amount.



GGeenneerraall NNoottee

� Before converting bills under LC, LC conversion should have been completed. � All charges that are picked up during the Conversion upload should be waived. � For funded Export Bills since interest is collected upfront and accruals are not there,

interest details will not be part of conversion. Hence Interest will be uploaded as waived. � Export Bills, which are overdue, should be manually converted and the status change to be

tracked manually through the life of the contract. � Extracted data from the current system will be uploaded in CBS through files. The data

extracted from the current system should be in the same format as required in the Upload files.

Securities Contract

CCoossttiinngg MMeetthhoodd aass WWAACC

� The weighted average cost for each holding of the security under a particular portfolio to be ascertained.

� The units/nominal will be the current outstanding position of particular security � The DSTL & MSTL date will be the conversion date. � The counter party will be the same as that of the original. � No accounting entries will be passed during upload. Generally most CBS systems provide the option to waive charges at the product level. � Price of security

o For securities type ZCB, then the current YTM to be ascertained taking into account the discount accrued till conversion date.

o For BONDS, price should include discount, premium & redemption premium accrued, based on the current accrual policy the bank follow.

For BONDS, the interest start date should be the last coupon date, so that CBS will accrue the interest receivable till date during EOD. Note: � MSTL will only happen online where the accounts hit will be conversion GL and bridge GL.

Hence the bridge will have only the money paid that is the net consideration. To this extent based on the accounting method, the bridge GL will have value less than the actual asset GL in the old system by this amount.

� The Asset GL will match only after the EOD.

CCoossttiinngg MMeetthhoodd aass LLIIFFOO//FFIIFFOO//DDMM

� All trades creating that position will be booked as buy/sell transactions with all transaction details including price, value date & counter party remain unchanged from the original transaction.

� The customer (settlement account) for the entries generated by CBS while doing Money Settlement for the Deal would not be passed.

� Interest accruals (from the current coupon start date to conversion date) and premium/discount amortization (from the purchase value date to conversion date) will be calculated and booked automatically in CBS.

� For transactions, which are in the previous coupon period, the bought/sold interest accounting entries in CBS would have to be reversed out using journal entries.



NNoottee

�� Since the volume of securities contracts are very less, on conversion date BO report will be provided from legacy system and based on this report the contracts have to be captured manually.

Fixed Asset Management

All fixed asset related information to be converted manually.

Concluding Remarks This document covers high level data conversion strategy for migrating the bank’s existing systems in to CBS and is formulated after taking into consideration a common approach to suit the different CBS Products. The specific detail applicable to the products needs to be incorporated in consultation with the CBS vendor.