/*Blog module replace 'read more' text*/

Data migration experiences in building a bank’s Customer Master Database - Part 1


Follow MINDSPIRE on social!

Feb 5, 2024 | Data Migration Blog

Our company, MINDSPIRE Consulting, has gained practical experience in many data migration projects during the last decade.

In our post along with our multi-year experience at a large Hungarian bank we review the typical tasks, challenges and lessons learned that we have encountered.

In the first part of our series of articles, we review our banking data migration activities carried out during the first period.

In the second part we cover our latest activities and summarize the lessons learned.

Initial situation: Segmented storage of the bank’s customer data

Our company, MINDSPIRE Consulting, was commissioned by a large Hungarian bank in 2018 to support the development of a Customer Master Database (or CMDB) for the financial institution in relation to the technical tasks of data migration.

While the challenges, solutions, methodologies, and tools mentioned in this post are based on the experience of a specific project, they are also typical for customer data migration in general.

The purpose of this post is therefore to share our experiences that may be instructive from a professional point of view, in addition to describing the task in question as a case study.

Kamilla Szerletics

Kamilla Szerletics

Banking Data Migration Expert

Kamilla has more than 10 years of experience in the financial sector, with a proven history of working with data migration projects, including data migration tool developments.

She is involved in the full data migration cycle, including planning, coordinating migration processes, mapping source and target systems, maintaining migration databases, functional testing, and supporting UAT activities.

Besides working as a banking data migration expert, Kamilla is managing banking data migration projects since 2019, and acts a product manager for MINDSPIRE DELTA Banking Data Migration Tool.

Based on the management’s decision, the aim was to develop a solution in which all the bank’s customers’ data could be stored in one application.

On the one hand, this was necessary because, in addition to the bank’s Core Banking System, customer data was stored in a number of isolated systems, and on the other hand, a significant amount of customer data stored in different applications was also acquired by the bank during the various acquisitions and mergers.

The storage of bank customer data in disparate solutions and the lack of synchronization of data creates several operational difficulties and risks, some of which have had a negative impact on customer satisfaction.

For example, if a retail customer wanted to delete a phone number previously provided to the bank, the administrator would remove it only from the system she or he were using, as they were not able to identify other applications that contained the same information. This meant that the customer was subsequently called again by the bank’s staff on the telephone number which he had previously explicitly requested not to use for this purpose.

But even when a new customer data was entered, there was no guarantee that the information would be automatically transferred to all the bank’s relevant systems, so customers had to enter the same information several times, which also reduces trust and satisfaction.

To avoid these problems, the need to create a Customer Master Database for the financial institution was born.

Developing a Customer Master Database for the bank

The financial institution’s first task was to select a system that could meet the expectations set by the complex banking data model, as well as the high standards of data security required by the industry.

The solution needed to store much more information about a customer than the basic name, address, and contact data. This is because the data model used by the bank contains thousands of fields organized in several datasets. In addition to the basic data, ID numbers, other system identifiers, statements, customer relationships, roles (e.g. bank account holder, trustee, lender) and contact data, the usability of each piece of information in the system has to be managed, making it much more complex than it might first appear.

The bank chose a solution from a vendor well known in the market to create the Customer Master Database, but the basic system had to be modified due to the complexity of the data model. Also, a number of data tables and fields had to be added, following and adapting to the bank’s previous customer data model. These specific adaptations to the standard solution require continuous attention during the software version updates, the data migration of new satellite systems, and in case of changing business requirements.

As our company, MINDSPIRE Consulting, also has significant experience in planning and implementing complex and time-consuming bank data migration projects, the bank’s management decided to involve our experts in the multi-year program.

MINDSPIRE’s data migration toolset

We have extensive experience in data migration, including banking data migration, complemented by our tools, methodology and templates.

During our projects, our in-house developed solution, MINDSPIRE DELTA data migration solution supports our experts’ activities, providing a powerful, ready-to-use, parameterizable data transformation and process management solution.

Based on a universal approach, our financial institution data migration methodology provides clearly defined tasks, responsibilities, and continuous methodological support throughout the project. Our methodology covers conceptual design, implementation, post-implementation support and coordination for different bank data migration projects.

Our documentation and reporting framework provides templates, checklists, reporting templates and other support materials for financial institutions for effective planning and implementation.

Delta Tool data transfer Erste 2022

The first data migration: Initial data upload to the Customer Master Database

In the first phase of the development of the Customer Master Database, the Core Banking System (CBS) was used as the customer base, as it was the primary repository for customer data.

Compared to the new Customer Master Database to be developed the bank’s account management system stores customer data in only a few tables, with reduced data content, validation, and options; from there, data had to be migrated to the new solution in a more complex data structure with additional options.

The target system, in which the bank’s Customer Master Database was created, was still completely empty at that time, so the first data import, the so-called “bootstrapping”, took place. During this process, the banking data migration experts of our company, MINDSPIRE Consulting, transformed and loaded the basic and additional data of two and a half million customers.

As data management in the bank’s core banking system did not cease after the migration, it was still necessary to ensure that administrators could record and modify information in the solution, including the creation of new customers. For this reason, a two-way synchronization between the two databases had to be established, integrating the two systems.

The rationale and benefits of a new Customer Master Database of the bank

This may raise the question of the rationale for creating a Customer Master Database for the bank in addition to the CBS solution, if both systems store exactly the same data.

The data model of the new CMDB solution is far more complex and offers much more possibilities than a few simple tables in the core banking system.

The application also includes advanced data validation functionality, which means that the data entered by the bank’s employees is validated in real time before it is actually stored, covering all fields, with an eye on individual business needs and context.

Previously, in the CBS system, it was possible to enter any number in a document identification field in a fixed format and including alphabetic characters, or three dots for the customer’s name, because the data entered was not verified. The consequence of this was that it was possible to record data incompletely or in an incorrect format, which obviously had a negative impact on the quality of the bank’s customer data.

This problem has been radically changed by the introduction of the new Customer Master Database of the bank, which verifies each individual data in the systems involved, even during the upload process. The data to be recorded is validated by the CMDB and does not allow incomplete, incorrect, or incorrectly formatted data to be recorded to the new Customer Master Database. Document identifiers must be entered exactly as required, e.g. the ID card must consist of six digits followed by two letters, each member of the customer’s name is stored in a separate field, and the customer’s address details must be entered component by component to ensure that the administrator records the most accurate data possible. This is essential to enable the bank to reach its customers through different channels, for example, an incorrectly recorded address contact may have previously failed to deliver bank statements.

In addition to field-level validations, the solution managing the Customer Master Database also examines the different relationships between individual data. For example, it warns if a mandatory field is not filled in for a declaration or checks if the contact data being recorded already exists for the customer.

The system also performs deeper checks, for example, if the customer is affected by CRS or is a foreign taxpayer, the solution will also ask for additional mandatory data during the capture.

Creating a bank's central customer master illustration

Bank staff can still use the bank’s core banking system to enter or modify data, in addition to the interface of the new Customer Master Database.

The above tasks have been implemented during the migration project carried out by MINDSPIRE during the legacy upload by transforming the data stored in the CBS system into the new CMDB data model, in the appropriate format, complying with all the correlations, validations and mandatory fields. This required the development of a complex migration process, where the data of different customer types, such as individuals, corporate customers, sole traders, potential customers, were all transformed in different ways, following the existing banking needs and the requirements of the new data model. The initial loading of the clean, validated, and data model compliant data executed in the migration process enabled the functionality built around the new Customer Master Database to work.

Next phase: Integrating customer data from other banking systems into the Customer Master Database

Once the integration between the CBS system and the Customer Master Database was established, the next step was to synchronize customer data from other banking systems.

This included, for example, the application storing the data of ad hoc customers, information on beneficial owners, customer data contained in electronic contracts, all of which were stored in separate isolated systems.

So, in the second phase, the aim was to migrate the bank’s customer data stored in the other satellite solutions and synchronize the systems concerned with the Customer Master Database.

The first step for all the systems included in the Customer Master Database was to solve the initial loading and real-time synchronization of data. The latter required a significant amount of functional development, such as the development of the necessary webservices for each application, which was developed by other vendors in parallel with the migration project carried out by MINDSPIRE.

Following the project-specific methodology developed in the first phase, MINDSPIRE has successfully executed the tasks of the second phase, responding to new challenges.

The scope of this phase was continuously extended, until instead of the initial phased migration, the integration of other systems into the new solution and the integration of the customer contact data management system into the Customer Master Database was completed in one weekend.

Our experts were flexible in dealing with the constant changes and were able to reschedule and execute what was originally a multi-project scope into one going-live migration weekend.

The execution, carried out by MINDSPIRE’s five-strong banking data migration team, started at 4pm on Friday afternoon and lasted until late Sunday evening, with continuous data transfers and interactions, almost without interruption.

Creating a new Customer Master Database: Using customer contact details

The following year, based on the experience of live operations, a new requirement emerged from the bank. As it was not fully feasible to store and manage information on the usage of customer contact details (address, phone number, email address) in the Customer Master Database, the decision was taken in 2020 to have a new register alongside the CMDB in which customer contact details could be stored in a way that could be accessed and managed uniformly by all connected systems, making visible which system or service was currently using each customer contact (phone, email, address contact details). This will completely fulfill the request for all systems to use customer data in a uniform manner, and for example, when a phone number ceases to exist, no application should store it any longer.

Therefore, the next task was to build and populate this system, which also involved loading millions of records.

Parallel tasks: Managing bank acquisitions

In parallel with the development of the Customer Master Database, our customer assigned us several tasks to populate the data of the financial institutions that had been acquired in the meantime.

These projects also required considerable planning and attention due to the complexity of the Customer Master Database, the preparation, cleansing and validation of the data to be migrated.

Data migration for a banks central customer master illustration

The impact of the banking satellite systems to be integrated on the Customer Master Database

An additional challenge for the bank’s Customer Master Database was that the banking satellite systems integrated with the solution required more and more changes, modifications and additions to the data model and validations as well.

These changes also had to be reflected in the interface of the core banking system, which has not always happened immediately.

These also increased the complexity of the project and generated ongoing tasks for our experts involved.

The timing of the overall data migration process was affected not only by the technical complexity but also by the business-level planning tasks, the process changes and the organizational change management involved in the integration of the individual banking satellite systems.

In certain cases, the business unit using the solution and the users did not necessarily support the integration of the data stored in the application into the bank’s Customer Master Database. For them, the inclusion of the source system meant additional tasks, as improvements and modifications had to be made to the solution they were using, processes were modified and possibly became more complex, and the process of data entry and modification changed.

Due to user needs and expectations, in many cases information is still recorded in source systems in a format different from the data model in the bank’s Customer Master Database. In such cases, the necessary transformation rules must also be developed during the data synchronization process in the background, which allows the two systems to be aligned.

Due to the different customer data stored in each system, the task of MINDSPIRE was not only transforming the data from the given banking satellite system and migration source system into the Customer Master Database, but also modifying the data of each of the related systems.

Namely, in order to achieve synchronization when migrating the different systems, i.e. to ensure that the data are stored in the same way in the systems after the connection to the CMDB, it was necessary to perform the reverse transformation and migration. Thus, in the migration process developed, first the data of the initial source system is transformed into the format of the target system, the data is loaded there, and then this data is transformed again, according to the synchronization rules applied to the system in the functional operation formulated for the system and loaded back into the source system.

The main reason for this is that it is essential to clean the data and adapt it to the needs of the target system during the transition, and the same changes must be made to the source system.

This creates a multi-directional migration process, in a closed migration database, where data is consistently passed around between the systems involved. After the migration to the CMDB, it would be possible to start a one-time synchronization between the systems for the currently migrated data, but since this always involved a larger amount of data, technically the initial synchronization is also done by migration, with bulk data loading.

In the second part of our series of articles we cover our latest activities and summarize the lessons learned.

Please see MINDSPIRE’s related:


Data Migration

Data migration services icon 2022

Data Migration Tool

Data migration experiences in building a bank’s Customer Master Database – Part 1
Project management contact form

Do you have a question or comment about this post?

Send us your message and our experts will contact you!

Data migration icon

Our latest Data Migration References

Are you interested in our Banking Data Migration services?

You can find more information here:

Share This