Transformation of the IT landscape in the bank

Hello! My name is Dima Zykov, I am the architect of the Rosbank corporate architecture office.

Today I will tell you how we are changing the IT landscape in a bank using the example of updating the General Ledger – the main bank system that automates accounting and stores data on transactions in accordance with the rules and requirements of accounting of the Bank of Russia.

Background of the project

The General Ledger has 2 main functions: processing business events with their subsequent transformation into accounting events and storing events that have already been transformed according to the accounting rules of the Bank of Russia.

Also in banking organizations there are several types of accounting – our project deals with accounting and product accounting. Product accounting also requires the implementation of its logic in the Bank’s systems.

The practice of past years in the banking environment has shown that the implementation of accounting algorithms can be easily combined with the implementation of the logic of product accounting in some systems, and this did not cause difficulties in the maintenance and development of such systems. However, over time, the number and variety of banking products increased, which led to the fact that the product accounting in the CORE BANKING segment became more and more. The accounting logic, strictly regulated by the regulator represented by the Bank of Russia, inevitably began to increasingly impose restrictions on changes and development in the product logic. Business requirements grew, market dynamics and factors changed.

At the first stages, many banks solved this problem by introducing additional ABS in the CORE BANKING segment of the architecture, and accounting was consolidated in a pre-selected master system with a general ledger, or in a system for generating regulatory reporting and separate accounting engines that was taken out to the side. All this led to the fact that the complexity of such IT landscapes increased and with each new implementation the situation only worsened, increasing the time-to-market and reducing the efficiency of return on investment.

Figure 1. One of the many options for IT architecture in the era of frequent global transformations in Banks

At some point, we realized that the monolithic architecture of CORE BANIKNG systems outlived its obsolete and service-oriented architectures began to replace it. The need to transform the IT landscape became obvious, so we at Rosbank decided to launch a strategic program to transform the IT landscape.

As part of the program, we faced the following problems that had to be solved:

1. distributed accounting with frequent duplication of functions in different systems of the same architecture segment – with all the ensuing consequences;
2. ongoing processes of consolidation of financial results both at the close of the banking day and in the preparation of financial statements;
3. rigidly connected grocery and accounting at the system code level;
4. constantly growing business requirements for the development and variety of product logic;
5. increased requirements for fault tolerance for the mechanisms of integration of CORE BANKING segment systems with each other.

Implementation

We started with the development of a transformation methodology, principles and rules by which it will take place. We worked out several scenarios for the development of IT architecture and chose the optimal one, according to the corporate architecture.

The first stage in the development of a new IT architecture was the study of the processes of accounting and product accounting and their distribution among several ABS of the bank. A functional architecture was drawn up, on which the main concentrations of functions in systems were noted. As a result, a platform-based approach to organizing segments of the IT landscape was formed.

Within the framework of the IT landscape transformation program, the main phases of the implementation of the new general ledger were identified.

• The first phase implies the implementation of only the general ledger module and its parallel operation together with the existing ABS. This mode of operation will duplicate the functionality of the systems, but will allow you to test the solution from the vendor and more confidently switch to it with the introduction of the next phase.

Figure 2. High-Level-Architecture (hereinafter HLA) of the first stage of implementation of the new General Ledger of the Bank, the stage of mirroring

• The second phase is the implementation of a mechanism for transforming business events and their transformation into accounting events. From that moment on, all the bank’s product systems that require the reflection of financial results in accounting will be required to switch to event exchange with the accounting engine.

Figure 3. Target architecture (HLA) in the framework of the project for the implementation of the new General Ledger of the Bank

This two-phase approach will reduce the risks of working on the heart of a living “patient” and make the transition to a new architecture less painful.

Now the project for the implementation of the General Ledger is under active development.

What will it give us?

1. Separation of accounting and product accounting, which in due time will make it possible for product platforms to develop independently, implementing their own logic, independent of the regulatory requirements of accounting, in all its diversity.
2. The ability to quickly respond to changes in regulatory requirements in terms of accounting, because all accounting logic is implemented in one system.
3. Simple day closing mechanisms and distributed day closing mechanisms in grocery systems.
4. The ability to investigate in more detail the TCO of each individual business system.
5. Transparency in processes will increase and, as a result, the speed of response to business requirements will increase.
6. In the medium term, the time-to-market will begin to decline with an increase in the complexity and number of banking products.
7. The level of opportunities for further development of the bank’s ecosystem will increase.

Our solution to this problem is not the only correct one, and each bank can solve these problems in its own way. This is one example of how the standard “sores” of the IT landscape of many banking organizations are treated.

In the next article I will talk about the first problems of integration between systems that we encountered within the framework of this project, and how we solved them.