I am Nikita Klimov, Platform Owner Oracle FlexCube (FCUBS) for processing operations of corporate deposits, interbank loans, foreign exchange transactions and derivatives at Rosbank. Today I will tell you how we implemented the FCUBS platform and what is the uniqueness of this project for the Russian market. All the details under the cut.
To begin with, we were the first in Russia who dared to adapt the Western system to the realities of Russian accounting in such a complex product line as financial and capital markets. The task was complicated by the fact that we introduced the system not from scratch, but to replace the existing system, which has been working in the bank for about 20 years. Moreover, the system was located separately in the perimeter of the bank, which means that we had to develop integration with all external and internal systems.
System architecture is a classic three-link. In our case, the backend is Oracle 12c (although it has already been removed from support at the moment, and we are switching to 19c … but this is a completely different story) and frontend is IBM WebSphere. An experienced reader will immediately ask a question – why not use the native for Oracle – Weblogic? And, of course, it will be right, because this is the first thing that Oracle itself recommended to us. But it turned out that the standard server for the bank is the IBM WebSphere application server, in addition, we have ULA for this product, and it was decided to adapt the application layer to the WebSphere features. Not to say that this was a very difficult task, but there were still a number of peculiarities of organizing internal queues, and our team had to spend many hours at three-way conference calls with support for Oracle and IBM.
While we were trying to set up a test environment and show the interface to the project team, our business analysts performed GAP analysis, described the requirements for functionality and thought over data migration from the old system. I will not focus on data migration, as in fact, it is the process of filling in intermediate transport tables inside FlexCube. All this action was reduced to iteratively filling and reconciling data until the migration was successful, because the main thing is to transfer the desired value to the desired field of the table.
A distinctive feature of our implementation was that to replace the system with four-wheel drive and constant user participation, we created an event system on STP processes, which provided for minimal involvement of business users. Only a checkpoint is provided to control processing. To do this, we had to break down old business processes and build new ones.
As I noted earlier, the system out of the box was completely unprepared for Russian realities, starting with the lack of a chart of accounts and ending with tax accounting. In fact, it was just a core with a set of event models from which to build a spaceship. Therefore, armed with functional requirements from the business, we started developing our custom layer based on the core of the system. We developed our Accounting engine for generating twenty-digit accounts and started implementing STP processes. To exclude manual user intervention turned out to be a non-trivial task, and could not be solved only with the help of triggers at the DBMS level. I had to build event logic on the JOB and enter a task schedule. This, too, was not enough, and we had to use Quartz, on the basis of which we automated our workflow. As a result, the following happens in a fully automatic process:
- The contract comes to us from the Kondor + front-end system, and depending on its amount, it either automatically logs in or goes into business authorization;
- After successful authorization, the system analyzes the client – whether he is a client of the head office, which means his accounts are in GL1, or is it a client of the regions, which means his accounts are in GL2. There is another case when this is a completely new client, and then we must request it in our CRM system and, based on the information received, initiate the opening of necessary accounts for him in the corresponding GL;
- As a result of processing, the system online requests for account balances and, if any, generates and transfers the necessary entries to the corresponding GL, generates and sends SWIFT messages and payments to the ERC;
- Inside the day, standard operations take place in the system – repayments, interest accruals, early closure, etc.
- Various information about account movements, counterparties and contracts we automatically transfer to the Federal Tax Service, AML, Nostro. We also did not forget about the Internet-Client Bank, through which customers see what happens to their accounts after opening and paying off deposits;
- We prepare various information for mandatory and management reporting and submit it to DWH – it is worth noting that we both make classic views for collecting information and generate transaction logs for IBM CDC, which collects and aggregates this information online.
Here, for clarity, I will apply our architecture and say only that, in connection with the choice of frontend – IBM WebSphere, it was decided to abandon the standard for FCUBS Gateway, which is deployed as an additional application and works the old way with listners and queues, and go to work with MDB Activation Specification. As a result, we developed additional integration applications, published them on our server and connected to the bank integration bus for interaction with other systems.
In addition, we also use integration with Systematica Modullar tools based on TIBCO Rendezvous, which communicates with our front and is the entry point for all contracts and ETL IBM DataStage. At the same time, functionality on DataStage is used for integrations not related to DWH. For one of the GLs, the logic of the battle loading / unloading of data was specially developed, with the status and breakpoints checked to wait for calculations.
- Replaced the morally and technically obsolete system
- Based on the FlexCube core, they created their platform with unlimited options for parameterization and metering variations.
- Minimized user participation in the processing of the day
- We optimized the EOD runtime – 15 minutes instead of 3 hours earlier.
- We have created a competence center within the bank and we can support and develop the platform regardless of the supplier
- Almost unlimited, we can change the usability of the user interface and create any test screens of consolidated information for easy control
- Implemented a control point monitoring system for a continuous processing process
- We created a platform on which we are ready to implement any banking product