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

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

iGATE Global Solutions LTD

Page 2 of 23

Core Banking Software

Data Migration Strategy

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

iGATE Global Solutions LTD

Page 3 of 23

Core Banking Software

Data Migration Strategy

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 postconversion 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 modules 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

iGATE Global Solutions LTD

Page 4 of 23

Core Banking Software

Data Migration Strategy

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 banks existing system into CBS either automatically or manually, there are certain activities that need to be completed as pre-requisites related to setting up bankwide 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 prerequisite for automatic conversion programs to work. These Global Data setup would be created

iGATE Global Solutions LTD

Page 5 of 23

Core Banking Software

Data Migration Strategy

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 Banks 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.

iGATE Global Solutions LTD

Page 6 of 23

Core Banking Software

Data Migration Strategy

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.

iGATE Global Solutions LTD

Page 7 of 23

Core Banking Software

Data Migration Strategy

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 Mode of Remarks Responsibility conversion Bank IT SMS Bank level Security management upload parameters maintenance parameter setup Operation User Role Maintenance Creation of user role Manual setup Operation User Profile Creation of user profile Manual setup maintenance Manual setup Operation Currency holidays Currency holiday calendar Operation/ iGATE Local Holidays Local holiday calendar Manual setup For head office manual creation, remaining branches upload using PL/SQL upload Bank Bank parameters Bank parameter IT/Operation creation Manual setup For head office Operation/iGATE Branch parameters Branch parameter manual creation, creation remaining branches upload using PL/SQL Static values iGATE System dates Application dates Manual setup Operation Customer category Customer category maintenance maintenance Operation Messaging Parameters Messaging Parameters Manual setup Manual setup Operation Purge Maintenance Purge Maintenance Static values iGATE Overrides table Error codes details Auto upload Upload from Treasury 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 Setup Operation Currency rates Currency rates Entity Description

iGATE Global Solutions LTD

Page 8 of 23

Core Banking Software

Data Migration Strategy

Amount Text Customer, currency Settlement instructions Product Groups Customer Account class Limits template details Credit Limits Collateral types Collateral details GL Chart of Accounts Accounting period code maintenance Transaction code maintenance Account revaluation maintenance MIS classes and codes Journal Entry Parameters Status codes maintenance Interbranch Parameters

Amount Text Customer, currency Settlement instructions Product Groups Customer Account class Limits template details Credit Limits

Static values Upload Manual setup Manual setup Manual setup Upload Bank to decide the limit line structure Bank to decide

iGATE iGATE/Bank IT Operation Operation Operation Bank to get back Operation Operation Operation Operation Operation Operation Operation Operation Operation

Manual setup Collateral types Manual setup Collateral details GL Chart of Accounts upload Manual setup Accounting period code maintenance Upload Transaction code maintenance Manual setup Account revaluation maintenance MIS classes and codes Manual setup Manual setup Journal Entry Parameters Manual setup Status codes maintenance Manual setup Interbranch Parameters

Messaging
Entity Advice Format Customer Address BIC Code Description Advice Format creation for all modules Customer advice maintenance BIC code maintenance
Auto upload Upload

Mode of conversion

Remarks

Responsibility
Bank IT/iGATE iGATE

All required BIC iGATE/Bank code will be upload taken from swift alliance. Only list banks which have key arrangement will be uploaded

iGATE Global Solutions LTD

Page 9 of 23

Core Banking Software

Data Migration Strategy

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 minors data should be cleaned up as a pre migration cleaning activity before taking it into new system. If employees 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.

iGATE Global Solutions LTD

Page 10 of 23

Core Banking Software

Data Migration Strategy

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 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.

iGATE Global Solutions LTD

Page 11 of 23

Core Banking Software

Data Migration Strategy

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. 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.

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 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. Transactions value dated less than the migration date will not be allowed in new system after migrating to new system. 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.

iGATE Global Solutions LTD

Page 12 of 23

Core Banking Software

Data Migration Strategy

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

iGATE Global Solutions LTD

Page 13 of 23

Core Banking Software

Data Migration Strategy

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

iGATE Global Solutions LTD

Page 14 of 23

Core Banking Software

Data Migration Strategy

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 dates inward clearing file will be reflected as a debit in the customers 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.

iGATE Global Solutions LTD

Page 15 of 23

Core Banking Software

Data Migration Strategy

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 datamapping 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 Banks 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-tofield mapping of each of the fields would be agreed and signed off by iGATE conversion team and Banks 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 banks 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.

iGATE Global Solutions LTD

Page 16 of 23

Core Banking Software

Data Migration Strategy

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.

iGATE Global Solutions LTD

Page 17 of 23

Core Banking Software

Data Migration Strategy

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.

Regular Contracts - bearing Fixed and Floating Rates 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. Regular overdue Contracts - bearing Fixed and Floating Rates 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.

iGATE Global Solutions LTD

Page 18 of 23

Core Banking Software

Data Migration Strategy

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. Irregular Amortized Loans 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

iGATE Global Solutions LTD

Page 19 of 23

Core Banking Software

Data Migration Strategy

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

Foreign Exchange
Spot Contracts 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. Forward and Swap Contracts 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. FX Revaluation 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 LCs 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. Note 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.

iGATE Global Solutions LTD

Page 20 of 23

Core Banking Software

Data Migration Strategy

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

Bills and Collections

Collection Bills Incoming and Outgoing 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. Outgoing Purchase Bills 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. Import/Export -- Acceptance/Negotiation Bills under LC 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 LCs will be uploaded with current outstanding amount. Import Payment Bills under LC 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. Discounted Export Bills both under LC and non-LC 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 LCs will be uploaded with current outstanding amount.

iGATE Global Solutions LTD

Page 21 of 23

Core Banking Software

Data Migration Strategy

General Note 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
Costing Method as WAC 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. Costing Method as LIFO/FIFO/DM 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.

iGATE Global Solutions LTD

Page 22 of 23

Core Banking Software

Data Migration Strategy

No te 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 banks 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.

iGATE Global Solutions LTD

Page 23 of 23