Attempting to maintain familiar third-party software within a corporate perimeter results in uncontrolled IT budget growth for financial institutions. For the transition to a new version of the platform, the vendor demanded a large sum, and for migration from the old version asked to pay a second time for the same data volume, since the migration tool was not included in the baseline contract. Financial stability of the IT budget was at stake as a commercial supplier attempted to shift regulatory costs onto the client. In this situation, transitioning to in-house development becomes the only way to regain control over the unit economics of customer support.
The actual catalyst for revising the strategy was regulatory requirements: in the spring of 2022, Presidential Decree No. 166 on the technological independence of critical information infrastructure was issued. Previously, the bank used a domestic supplier's solution assembled on foreign components for retail customer service. Inside this system operated an NLU engine that resolved about 60% of customer inquiries without the participation of contact center operators. However, the supplier accompanied the release of the import-substituted platform with invoices not only for licenses, but also for the migration process itself and the re-integration of modified protocols.
Engineering stack and the economics of license rejection
In-house development required building a stack from scratch, but eliminated constant license payments to third-party companies. Engineers built the backend of the new chat platform on Python 3 and FastAPI, and the user interface on TypeScript and React, setting up data exchange between the client and server via the SSE (Server-Sent Events) protocol. Postgres Pro became the database, while inter-service transport was organized via HTTP and Kafka depending on the load type.
The internal App.Farm PaaS platform assumed infrastructure responsibilities, sparing the product team from the need to administer clusters.
Infrastructure backing was provided by the bank's internal App.Farm PaaS platform. Thanks to this, the retail chat development team was able to focus on product logic with a minimal headcount: 3 backend developers, 2 frontend developers, 2 QA engineers, an analyst, and a product manager. Previously, the bank had already designed and tested its own platform on corporate clients, so the integration cost of the solution for the retail segment proved to be nearly zero.
Scenario migration and in-house development risks
Defeating the vendor's strategy meant losing years of accumulated speech comprehension algorithms: the third-party NLU engine was finely tuned, whereas the proprietary bot started with a clean slate. How was the accumulated knowledge base transferred without purchasing tools from the supplier?
Migrating dialogue scenarios from the legacy system required manual data parsing. The internal development team demanded constant maintenance costs for a staff of specialists instead of simply purchasing ready-made licenses, but this move completely eliminated dependence on an external supplier's pricing policy and third-party development queues.
Deep integration within a single perimeter allows the bot to independently block bank cards and change customer PIN codes without transmitting standard instructions.
Direct access to the banking core removed the limitations of boxed software, where every integration modification had to be paid for twice — to the supplier and to internal developers. As Oleg, managing director of the Financial Technology Development Center at Rosselkhozbank, noted, an in-house development team costs more than regular license fees, but it eliminates dependence on third-party development queues and external technology contracts.
The commercial supplier intended to sell the bank its own data migration tool on top of a new licensing agreement, but the financial institution chose infrastructure control instead.
What it means
Escaping the risk of unpredictable license fees forces financial institutions to trade off polished vendor tooling for the ongoing overhead of an internal engineering team. Rosselkhozbank's case on Habr shows how vendor invoices for data migration pushed the bank to build an in-house stack on Python 3 and FastAPI with a compact team of nine specialists. Will a team of three backend developers and one analyst manage to match the former 60% automated resolution rate without the mature third-party language engine?