Importance of Data Reconciliation in Core Banking Implementations

Data Reconciliation is one of critical activities in any migration process. Usually, the customer of the bank is more concerned about his financial balances held with the bank rather than the software migration or upgradation activities undertaken by the bank. Sensitive financial data of the client should be reconciled both pre and post migration activities. Hence it is imperative on the part of the financial institutions to carry out the data reconciliation activity with due diligence.

Normally, the data migration would be done in two ways, i.e. Big-bang approach and Phased manner approach. It is to be ensured that the data reconciliation process is initiated in the mock migrations planned before actual migration, duly identifying the data to be reconciled, so that the reconciliation would be smooth in the final run. The aim is to ensure that the financial / non-financial data is unchanged pre and post migration. However, if there are any changes, it should be accounted for and documented. Due care to be taken to reflect the failed records during migration, in the reconciliation process.

The approach for data reconciliation between source and target systems can be broadly classified into the following categories.

1. Financial Data Reconciliation
2. Non-financial critical business data reconciliation
3. GL level Reconciliation
4. Technical Data Reconciliation
5. Count based Record reconciliation

Financial Data Reconciliation:

Business team should identify the modules for data reconciliation, prepare the templates duly identifying the financial data elements and generate the balancing reports for source as well as target systems. These balancing reports can be generated branch wise / cost centre wise / bank wise, depending on the migration approach adopted and the decision of the business team.

A few data elements for illustration purpose.

• CASA – Account balance, Currency, interest accruals etc., for all the accounts.
• Deposits – Principal balance, Currency, interest accruals etc., for all the accounts
• Loans – All loan contracts with all the components like outstanding principal, interest accrual, principal overdue, interest overdue, etc., for all the loan contracts.

Non-financial critical business data reconciliation

Business Team should identify the critical business data from the migrated modules for comparison between source and target systems to ensure consistency. The report templates are to be formulated and to be generated from source and target systems during migration and the data is to be compared.

A few data elements for illustration purpose.

• Customer – Important data elements like Customer Code, Customer Name, Date of birth, Address etc., basing on the decision of business team.
• CASA – Account Master Data like Account Number, Customer Number, Account name etc.,
• Deposits – Account Master Data like Account Number, Customer Number, Account Name etc.,
• Loans – Account Master Data like Loan Contract Number, Customer Number, Borrower Name, Loan Currency etc.,

GL Level Reconciliation:

This is very important part of Reconciliation activity. Normally banks may use i) built-in GL systems in the legacy / core banking application ii) a separate GL Accounting system with the data feed from the core banking system  iii) routing the data feed from core banking system through an intermediary engine, where specific accounting entries are generated as per the country specific accounting guidelines and interfacing to GL system.

In all the cases, the existing and proposed GL accounting systems (source and target) are to be studied with reference to updation of accounting entries, interest accruals, closing balances. The existing GL accounts are to be mapped to the target GL system and reconciliation template is to be designed to reflect pre and post migrated GL balances. The accounting entries that take place during migration process pre and post are also to be reconciled.

Technical Data Reconciliation:

This part of reconciliation activity is to ensure that the selected data for migration from source system has been migrated properly to the target system, leaving the failed records. Necessary scripts to be designed to compare the table and column level data values from source to target as per the mapping sheets prepared during migration workshops. The mismatch report can be generated module-wise and analysed for impact and to take necessary corrections in the migration tool.

Count Based Record Reconciliation:

Another important aspect of reconciliation is the matching of number of accounts, interest records, repayment schedule records etc., before and after migration. During migration, the data would be selected from the source system, transformed as per the agreed transformation rules and migrated to the target system. In this process, there is a chance of failure of some of the records in some of the stages of migration. A script to be designed and the metrics to be extracted from source and target systems, duly accounting for failed records,  at each stage of migration and the count of the records to be tallied pre and post migration.