Reiknistofa Bankanna (RB) is an IT service centre for the Icelandic financial market covering all aspects of IT services: development, maintenance and operations of IT-systems. RB has been a long-standing service provider for the Icelandic financial market.
We talk with Kristrún Arnarsdóttir, test manager of Reiknistofa Bankanna about doing full reconciliation of multiple large-scale current accounts and deposit accounts migrations. RB is in the process of replacing its bespoke systems with the Sopra Banking Platform.
Kristrún Arnarsdóttir
Test Manager at Reiknistofa Bankanna
What is reconciliation?
Reconciliation is making sure everything is right. When data is migrated, that it is correct and complete. We do that by automatically comparing the migrated data with the original data. We also compare the data after processes like the daily interest calculation have been run.
That sounds simple.
Yes, it does. However, when you compare data in different systems, it is like comparing apples and oranges: difficult to compare.
Fortunately, at RB we have - what we call - a DataSquare. In the DataSquare, we represent the data in our systems in a unified format - an ontology. When we implemented Sopra - our new system - a requirement was that Sopra would deliver its data to the DataSquare in the same unified format.
In computer science, an ontology encompasses a representation, formal naming and definition of the categories, properties and relations between the concepts, data and entities that substantiate one, many or all domains of discourse. Knowledge graph is sometimes used as a synonym.
This gave us a good head start in being able to compare the data in the old system with the data in Sopra. But even then, many things were different, for example how products were categorized and represented.
Although the DataSquare contains a lot of the data elements, it doesn’t cover everything. We dealt with those elements separately.
In the end, we did a full reconciliation: all data elements that went into the migration process were compared!
How important was the DataSquare for making this full reconciliation?
Having a shared ontology really makes a big difference. When you don’t have an ontology you need to prioritise on risk and money. We have experienced ourselves that comparing data that were not part of the DataSquare is very time-consuming.
All those detailed comparisons are not ‘steering group ready’ information.
Yes, correct. Finding the right representations that are understandable for the different stakeholders of the project is an important task.
For example, from a business perspective, accrued interest is important. We realised that accrued interest would be different between systems for numerous reasons. For example, the way it is calculated is slightly different. Accrued interest is important because it is correct only if all financial transactions are correct, the interest rates (both historical and current) are correct, and, finally, the product mapping is correct.
We represented the results as a spread where the differences are visualised. The horizontal axis contains the difference in accrued interest, the vertical axis shows the number of accounts. The accrued interest difference in Krona was divided in buckets of 0-2, 2-5, 5-10, 10-100 and >100 both positive as well as negative. (Note to the reader: 1 Krona = 0,0073 EUR)
Below, you’ll see an impression of this report.
This allowed us to differentiate between small issues stemming from calculatory mismatches and differences that had other causes and warranted further investigation. Also, it gave the stakeholders a good representation of the actual differences and progress of the project.
Did this reporting also help in analysing the cause of differences?
Yes, the report allows us to drill into the individual differences up to contract level, so that we can make a detailed analysis of the cause of the differences.
Good tooling to help perform analyses and report results is very important - a lot of time and effort was put into it. We created the reporting/analysis tools as a web application using Oracle Application Express (APEX) on top of the database.
Was an acceptance criterion formulated about these differences?
No, acceptance criteria were established during the project, as part of the process. It was an iterative process - each iteration built trust. For example, when you ask: ‘What difference is acceptable’, you may get back: ‘No difference is acceptable’. So, you need to have a process that allows you to visualise the differences, analyse them and communicate about them so your customer understands and accepts the causes or fixes.
You’re very experienced doing data migration testing. What are your learnings?
Having a shared ontology is of great value if you want or need to do a full reconciliation.
Spend time on tooling for presentation and analysis.