The story of how IKB was connected to OBI (and why OpenAPI is here)

Short description

The Competence Center for Integration Solutions of the ICB implemented the OpenAPI specification, which connects banks to the trusted environment of the Bank of Russia’s Open Banking Interfaces to enable digital data exchange with service providers and customers. The eKassir company offered a ready-made “boxed” solution that implements the support of the Bank of Russia Security Standard STO BR FAPI.SEK-1.6-2020, as well as two applied standards. The pilot project started in March 2022, and the OpenAPI Adapter was evaluated by internal and external experts before final testing and certification on the stand. The solution allows for the convenient exchange of information, reduces expenses, and ensures quality and security for banks.

The story of how IKB was connected to OBI (and why OpenAPI is here)

Implementation of new information technologies in the bank is always a compromise. How would we, on the one hand, do better for the client, on the other hand, not to cause negative comments from IS colleagues, and on the third hand, think through the perspective and prove its benefit for the entire bank in general. It is also necessary to distinguish the grain from the chaff and understand which technology will be more promising in the long run.

Hello everybody! My name is Oleksiy Sharnenkov, I work as a department head at the Competence Center for Integration Solutions of the ICB. Below I will talk about why we implemented the OpenAPI specification, what difficulties we faced, and why we still believe that it is worth it.


In October 2021, we finished accepting applications for participation in the “Continuous IT Innovation Acceleration Program”. The purpose of this program is to find promising technological projects in the field of fintech. The digital world is constantly changing, and the banking sector is riding the crest of this wave, albeit with a serious eye on security.

Business units identified eight key areas, one of which was OpenAPI solutions. This specification is intended to connect banks to the trusted environment of the Bank of Russia’s Open Banking Interfaces (OBI) to enable digital data exchange with service providers (with the client’s consent) and customers and the provision of financial services.

The implementation of the specification ensures the convenience of information exchange between market participants and the reduction of costs for the introduction of new products. In addition, at the initiative of the Central Bank (CB), the FinTech Association is actively studying the possibilities of OpenAPI. In the future, this will lead to the creation of new standards on its basis, mandatory for everyone, and in this case we will be among the innovators, who will already have everything ready.

What is the OpenAPI specification

Let’s agree that we will not analyze the specification to the smallest detail within the framework of this material: although this is an article on Habr, the OpenAPI itself is perfectly described elsewhere. Moreover, for us it was a partially “boxed” solution.

The specification does not require access to the code, which simplifies the transfer mechanism: there is no need to think in what language the “receiver” is written. The specification is presented in two formats, JSONwhich is convenient for the interaction of information systems without human participation, and YAMLin which a person of a certain skill has a good chance to understand if necessary.

This makes it clear why the Central Bank sees OpenAPI as the future standard in the industry. Banks use different solutions, and the new specification will make it possible to switch to a single standard, according to which everyone will conveniently exchange information. The “openness” of the solution in this case will not be a problem, but rather, on the contrary, it helps to close the vulnerabilities as soon as possible.

In the future, OpenAPI should become not just a standard, but a whole philosophy based on unification. It will allow the use of general legal regulations and test certification regulations. The key benefit for banks will be a reduction in value, both in terms of time to develop a solution and in terms of ensuring quality and security.

Why can’t it be so simple to take and do

When you want to deploy a complex information system within an organization, there are several paths you can take. The first way is internal technology. For this, you can use either employees who have the necessary competencies, or invite new specialists. But a staff that expands without limits is not the most elegant business model. Endlessly transferring employees from the project where they already work to something new will not work either. And while we all love new challenges, sometimes you have to admit that development shouldn’t come at the expense of strategic challenges. Therefore, there is a second way.

It is more flexible and involves hiring an integrator team. On the market, you can find professionals who have already achieved success in solving a specific task or have experience in related areas. We followed this path by placing an application for the implementation of a solution based on OpenAPI, which would allow joining the OBI environment of the Bank of Russia. eKassir, a software developer for banks and credit organizations, responded.

What eKassir offered

The eKassir company turned out to be the only one that offered us a ready-made “boxed” solution. Such software is usually “filed in place” according to the needs of the customer, but frees you from the need to get involved in custom development. Pros of the solution: trial run on other projects and cost. Their full product is called eKassir OpenAPI Adapter.

This software implements the support of the Bank of Russia Security Standard STO BR FAPI.SEK-1.6-2020, as well as two applied standards: “Open banking interfaces. Obtaining information about the client’s account by a third party” and “Open banking interfaces. In addition, the Open API Adapter authorization server uses the same solution as in the certification stand of the “FinTech Association” – eKassir Access Manager.

OpenAPI Adapter has been thoroughly evaluated by internal and external experts. We were more than satisfied with the results of the audit.

You can easily extract Docker from Kubernetes

The pilot project started in March 2022. According to the plan, all components of the OpenAPI Adapter were to be implemented in the infrastructure of the MKB by May 31, and the bank had to successfully pass the certification at the stand of the “FinTech Association”. All works can be conditionally divided into 3 stages: prototype assembly, use, final testing and certification on the stand.

The first stage: we collect the working configuration at the contractor’s stand

It didn’t make sense to start working immediately on the IKB stands: firstly, it is not so easy for a third-party developer to start doing something inside the bank’s contour, and secondly, it did not carry any meaningful load. All “rough” work could be done on your own servers. At the same time, the infrastructure had to emulate the ICD. For this, eKassir used the Postman API platform.

After the preparatory work was completed, the solution was submitted to an internal audit, where problems were revealed: several .NET and JavaScript libraries used in the OpenAPI Adapter were found to be vulnerable. This happened due to the fact that several months passed between the launch of the certification stand of the Fintech Association and the pilot project at IKB, during which the OpenAPI standard managed to change. It also now required a transition to a Secure SDLC software development process. In short, it is a methodology aimed at producing hack-safe software. According to this methodology, finding a bug at the development stage will cost many times less than patching a vulnerability after release. It also took time to adjust our processes to new requirements.

Stage two: the container ship arrives at the port

A problem that was not given enough attention at the start was revealed. The eKassir team handed over the configured Docker containers to colleagues at IKB, but the problem was that IKB was already using Kubernetes. It took time to adapt the different containerization environments to each other, but in the end the task was solved, although some of the configuration settings were lost in the process.

After unpacking the containers, you need to work a little more with the network infrastructure: configure proxies, issue certificates, finish configuring cryptography. The term of the pilot project, as you may have guessed, had to be extended.

Stage three: we knock on the test stand, we hear knocks in response

So, after setting up everything that was part of the solution complex, we had to pass the test tests at the certification stand of the Association of FinTech (AFT). It is built on the basis of the “Access Manager” solution of the vendor eKassir and is part of the technological sandbox of AFT. The stand is needed to test banking open APIs and applications for compliance with the standards of the Central Bank of the Russian Federation. Access to this stand is given to all organizations that have joined the “agreement on compliance with OBI standards”.

The “sandbox” module consists of 2 parts: “sandbox 0” and “sandbox”. The first part can be accessed by any organization registered on the OBI portal. There you can test APIs and applications with a limited set of scenarios without checking information security settings. Access to the second part is given only to organizations that have signed an agreement on compliance with OBI standards.

To protect data, the standard provides for the use of OIDC for identification and authentication, a compact format for transferring assertions between JWT parties, and the cryptographic mutual authentication protocol mTLS, which allows the client and server side to verify each other’s certificates.

When passing tests according to the standard of the Bank of Russia STO BR FAPI.SEK-1.6-2020, we encountered problems due to incorrect mTLS settings. The protocol itself did not cause difficulties, while the configuration of the WAF associated with it required adjustments. eKassir experts quickly clarified all the nuances and mTLS worked as it should.

To pass the official testing procedure, you need to send a request to the FinTech Association through the bank’s office on the website After that, a temporary window of 7 days will be opened, during which it is necessary to complete all tests with logging of the result. When testing in the “combat” module, scenarios similar to real life occur, that is, both positive and negative. The OpenAPI Adapter was successful in just 2 hours, while testing without it takes between 1 and 7 days.

What’s under the hood in the OpenAPI Adapter

In previous chapters, we referred to a number of different regulatory documents, technologies, protocols, and so on. Now let’s show how OpenAPI security mechanisms work.

OpenAPI security mechanisms

The basic thing is services inside the infrastructure that are unable to constantly communicate using complex protocols with constant authentication. Agree, it would be strange if you locked every room in your apartment with a key – you have a good entrance door and walls to protect against thieves. For the eKassir OpenAPI adapter, these doors are two Identity Gateways (IGs), which act as API Gateways. All this accumulation of words acts as a gateway that separates the external network from the Intranet (INT), the local network.

One IG is located in a DMZ network segment. This segment is available for both Internet and Intranet calls. It serves as a kind of buffer zone – we will consider it an apron in our metaphor, an additional safety border. IG INT communicates with it from the local network. The connection is initiated from the WSS trusted zone and is always open.

Identity Gateway enriches the account access application API with information about the consent resource and sends the enriched request to the Account Service. IG performs the work of FAPI.SEC, including linking the transport certificate to the access token, checking for identity, validating the digital signature of the application request body, etc.

Now MKL is a member of OBI

As you already understood, the project was successfully completed. MKB became a full-fledged participant in the OBI environment in the role of a payment service provider for the scenario “Receiving information about the client’s account by a third party” and gained experience working with the security standard FAPI.SEK-1.6-2020.

On the one hand, we did not meet the initial deadlines. But, as with any integration, and even more so with a banking regulator, this was to be expected. We solved the problems promptly, and the only thing that could have been predicted was the discrepancy between the contractor’s containerization mechanism and the one accepted by the bank.

OpenAPI Adapter has proven to be an excellent tool for solving a specific task in understandable terms. There might be a way to optimize something specifically for us or write a completely custom app, but the speed of development and implementation would definitely be slower. We did not find any pitfalls, the decision passed a strict audit: in banks it is not otherwise. Glad to know your opinion about the implemented solution and discuss alternative scenarios in the comments.

Related posts