Migration of an international bank's Retail Banking and Wealth Management Business
In end of 2016, D Bank, a bank mainly operates in Asia Pacific acquired A Bank, an international bank's retail banking and wealth management business. The migration project lasted for the whole year of 2017, and covered several key markets of A Bank. In Taiwan market, I was in charge of the conversion of 200K customer data.
project background
project scope
The overall objective was to migrate all retail banking and wealth management customer data (customer profile) and product data (including core banking products and credit cards) from A Bank, an international bank's core banking systems and other sub applications into D Bank’s core banking system and other relevant applications.
I was the focal point from tech side for Customer Profile work-stream, mainly in charge of customer data conversion.
purpose of cif migration
Migrate all mandatory and internally required customer data that are available at A Bank into the correct fields in D Bank’s core banking system ‘Finacle’ to meet the purpose of KYC, business analytics and regulatory reporting.
project timeline
From NOV 2016 to Dec 2017.
my role
sme of customer profile module in core banking system 'finacle'
DATA INSIGHTS & STRUCTURE REQUIREMENTS
Led discussion to prepare user requirements on data mapping.
Ensured requirements covered comprehensive correct A Bank fields to D Bank fields mapping.
DESIGN CONVERSION RULES
Designed conversion rules to be in alignment with business definition, operational processes, system behaviors and regulations.
PLANNING & VALIDATION
Monitored the completeness of UAT case preparation and execution to cover all requirements.
Ensured defects are spotted and fixed during UAT and DR period.
OVERSIGHT & COORDINATION
Prioritized and negotiated on changes required based on unmasked data from A Bank.
Facilitated to refine user requirements via CR and track CR status and result.
the challenge
Correct field-to-field mapping and technologically feasible conversion rules
There were 1,000+ data fields and both front-end field names and back-end field names may be different at the 2 banks.
Specific data may be maintained in different fields with different front-end field names.
Unlike D Bank, A Bank has 2 core banking systems, and they didn’t maintain all mandatory or internally required data in core banking systems, some data are stored in sub applications.
The structure of data maintenance was different at the 2 banks, e.g. which section of the data is stored in, number of fields used to stored a certain set of information, data input may vary between free text format, selection table or drop-down list… etc.
how i conquered the challenge
d Bank's information structure
Through the insights gained from interviews and observations, as well as system knowledge, I constructed information structure of Finacle Customer Profile module based on mandatory and internal use fields. As Customer Profile module is divided into Retail and Corporate modules, the below is for Retail customer as example. Corporate customers have another set of information structure.
For confidentiality reasons I have omitted the actual name for each category in information structure.
Further detailed information structure down to every single field were documented in Excel spreadsheet as reference for data mapping and conversion rules.
For confidentiality reasons I have omitted the actual field names.
close the gap
retrospective & reflections
Validate as early as possible
Validate the information obtained via research as early as possible. This could help us to avoid more changes required after software has been developed.
Information regarding D Bank’s data can be tested via trials in every non production environment – SIT, UAT and DR. However, information regarding A Bank data could not be validated till the later 1/4 phase of the project.
We were not allowed to see unmasked A Bank data till a late timing and we did not verify all points advised by A Bank in data mapping workshop as soon as possible. A few substantial issues could have been discovered and fixed in earlier DR’s if we had done so.
it takes what it takes
If you don’t trouble your user now, you’re going to trouble them later. Comprehensive testing is crucial. Testing on the software developed can never be over-detailed or too much.
There were several fields that we found having issues like A Bank had provided the wrong data, the conversion programming wasn’t fully in accordance with conversion rules…etc. till the last 2 to 3 DR’s because the samples checked by users in UAT and DR were not enough and thus the issues weren’t identified earlier.
For some of them, it was already too late to make program change so users would have to do manual cleanup or raise new UR to resolve the issues.