For the user, purchasing government bonds in mobile banking looks simple: choose an instrument, see the terms, sign documents, pay. But in reality, such a scenario often involves not «another feature in the application,» but a complete restructuring of internal processes, integrations, and architecture.
For the user, purchasing government bonds in mobile banking looks simple: choose an instrument, see the terms, sign documents, pay. But in reality, such a scenario often involves not «another feature in the application,» but a complete restructuring of internal processes, integrations, and architecture.
This was exactly what happened at Raif with the development of the OVDP service in the MyRaif application. The team needed not just to bring the investment product to the digital channel, but to change the very model of its passage within the bank: remove manual bottlenecks, synchronize more than ten systems, automate document flow, and lay the foundation for further scaling.
For a technical audience, this case is interesting not only for the product itself, but also for the engineering problem of how to translate a complex banking scenario from a partially manual model into a digital self-service without losing manageability, process control, and the possibility of future development.
Before the advent of a fully digital scenario, the sale of government bonds in the bank already existed. But the process itself was complex and fragmented: the client contacted a manager, then the transaction went through several departments, and data was transferred between systems partly manually. For single transactions, such a model can still work. For scaling, it no longer works.
At some point, it becomes clear: the problem is not that the customer does not see the button in the mobile application. The problem is that behind this button there is not a sufficiently flexible internal system that allows the service to grow without a proportional increase in manual participation.
For us, the key was not just to digitize the customer journey in MyRaif, but to create a foundation on which this service could be scaled further. We immediately understood that without new integrations, process orchestration, and automatic entry of information into systems, the product would very quickly encounter internal limitations. Therefore, we moved in stages: first, we gave the customer a convenient experience, and then we began to build an architecture that removes the manual workload within the bank.
This is what determined the team’s approach. The work was not only on the client scenario in MyRaif, but also on two planes: external — where the user gets a simple digital experience, and internal — where the bank builds the process and technical foundation to make this experience stable, manageable, and scalable.
Buying government bonds from a bank is not a single transaction in isolation. It involves checks, data, documents, statuses, routing, and information transfer between multiple internal and related systems. To make this scenario digital, the team had to rebuild a large number of interactions between systems, and create some integrations virtually from scratch.
The solution involves more than ten systems. To ensure that this chain works stably, the team relied on microservice architecture, BPM for orchestrating business processes, and an event-driven approach for building integration flows between systems.
In such a model, BPM became not just a tool for a «process diagram», but a mechanism for managing transitions between stages, processing statuses, controlling execution, and reducing dependence on manual intervention. The event-driven approach, in turn, made it possible to make integration flows less rigidly coupled and prepare the system for further development without completely redesigning each new scenario.
«We designed the architecture so that it would work not only for the current launch, but also for the next stages of development. This makes it possible to automate internal processes more quickly, reduce manual work, and further expand the service to new scenarios,» says Ruslana.
In fact, it was not about a single function in a mobile application, but about forming an architectural framework on which to build the further development of the investment direction.
At first glance, it may seem that the main complexity of such a service is in the interface: a list of bonds, selection of an instrument, amount, documents, signing. But in banking products, the most difficult part often begins outside the user’s screen.
It is necessary to ensure data consistency between systems, not to lose status at any stage, to correctly form documents, make payments, transfer the result to the next loop, and at the same time not to build another «temporary bypass» that will not withstand the next wave of development.
In such scenarios, architecture directly impacts business velocity. If every new step requires manual intervention or a «workaround» custom integration, the service quickly reaches its growth limit. If process and integration flexibility are built in right away, subsequent releases become cheaper, more predictable, and technically sound.
That is why the team at Raiffeisen viewed the launch of OVDP in MyRaif not as an end point, but as the first working layer of a larger system.
The service did not appear in its final form all at once. The team moved in stages.
Initially, MyRaif allowed clients to view their portfolio of government bonds. Then, they could order and receive documents regarding ownership and transactions on the securities account. The next step was a «showcase» of bonds, where they could select a specific ISIN and quantity.
After that, the team moved on to a full-fledged digital scenario: selecting government bonds, calculating the amount, generating documents, signing, and paying without a break in the customer journey.
This approach allowed us not to try to «close everything at once», but to sequentially digitize individual parts of the complex banking process, while simultaneously completing the internal architecture.
A focused team worked on the development of the service: backend developers, mobile specialists, QA, business analyst, architect, delivery function and related roles. For a large international bank, this is not a very large team. But it was precisely this compactness that made it possible to keep the focus on one end-to-end scenario and more quickly synchronize solutions between different areas.
In this case, not only the size of the team is important, but also the nature of the task itself. This was not a story about a separate frontend release or local refinement. The team worked at the intersection of several dimensions simultaneously: customer experience, document flow, integrations, internal processes, scalability and technical readiness for the next changes.
For a technical audience, this is a familiar type of problem where the main value comes not from a single service or screen, but from how resilient the entire system is and whether it can survive subsequent iterations without accumulating architectural debt.
After launching the automated script through MyRaif, the team saw the main thing: the service began to be actively used by customers, and the new approach worked not only at the level of customer experience, but also at the level of the internal operating model.
For the team, this was an important confirmation that the focus on automation, integration, and a new architectural foundation was the right one. When a complex process becomes shorter and clearer for the client, and less manual and better managed internally within the bank, the service gains real potential for scaling.
In this case, the result is important not as a PR argument, but as an indicator that the new model is working, the customer journey has become simpler, and the internal system is ready to scale without a proportional increase in manual workload.
The team sees the next stages of development in further automation of internal processes, lowering the minimum entry threshold, expanding the service to new scenarios, and further using the built architecture to develop the investment direction.
«We are building solutions with an eye on the future. When internal processes are fully automated, it will give the client more freedom, the bank 0 scalability, and the product a new speed of development,» says Ruslana.
And this is where this case goes beyond the topic of OVDP. In essence, the team at Rife was solving a universal problem for large financial systems: how to turn a complex, fragmented, and partially manual process into a digital service that can not only be launched, but also developed further without the technical debt that later begins to slow down any changes.
For the client, it’s a few simple steps in a mobile app. For the engineering team, it’s building a system that makes those few steps possible.
