Introduction: In the 2010s, the banking and financial services (BFS) sector had to take a radical shift. Giants once considered too big to fail had fallen into brankrupcy, customer trust dropped, and expectations changed drastically, driven by the acceleration of internet access and the emergence of the first smartphones.

To meet these expectations, traditional banks invested heavily in online banking and digital services. The rise of online banking significantly increased transaction volumes and intensified the demand on underlying systems. 😁

To support this shift, institutions began modernizing their infrastructures to address long-standing pain points. These included improving service quality, reducing inefficiencies and technical debt, and fostering greater collaboration and ownership across teams. At the same time, scalability became a critical requirement. Banks needed to handle a growing number of digital customers whose usage patterns were not only higher, but also increasingly volatile.

The Promise of Innovation

APIs: the engine behind the machine

On the surface, banking systems appear stable, almost immovable. In reality, they have undergone profound transformations over the past two decades.

As digital adoption accelerated, transaction volumes surged dramatically. Customers began interacting with their banks more frequently, executing payments, checking accounts, and managing financial products online. Money started moving faster, more often, and across more channels than ever before.

Legacy systems, originally designed for stability rather than speed, quickly struggled to keep up with this pace. To maintain service quality, banks introduced new, dedicated applications to handle specific use cases such as payments, asset management, lending, or insurance.

At the same time, the emergence of Open Banking and Open Finance reshaped the competitive landscape. By opening their systems through APIs, financial institutions enabled third-party providers and fintechs to build new services on top of existing infrastructure. This increased interoperability but also intensified competition, pushing the entire sector into a continuous race for innovation.

In this context, software development has become central to financial services. It is no longer just a support function, but the primary driver of innovation, enabling institutions to deliver new services, improve efficiency, and respond to constantly evolving user expectations.

When the ecosystem becomes increasingly complex

To sustain this pace of innovation, banks sought to modernize their development and delivery processes. Their objective was to improve efficiency, reduce redundant efforts in testing and deployment, and enhance the overall quality of the software being produced.

However, this shift came with unintended consequences.

Instead of simplifying their systems, banks progressively introduced hundreds of interconnected applications and services. While these architectures allowed for greater flexibility and faster development cycles, they also significantly increased complexity. Making even minor changes now requires navigating multiple dependencies, managing configuration layers, and ensuring compatibility across systems.

Over time, this complexity has grown exponentially.

A useful way to understand this evolution is to compare banking systems to a metro network. As the network expands, new lines improve coverage and connectivity, but they also increase interdependencies. A disruption on a seemingly minor line, such as line 10 in Paris, can contribute to the saturation of major lines like line 13, creating cascading effects across the entire system.

Banking systems have evolved in the same way. Each new application or API improves functionality but also increases dependencies. Over time, the system becomes more efficient, yet significantly harder to understand, modify, and secure.

In the same way, banking architectures have become dense, interconnected ecosystems where every new component improves functionality but also adds friction and risk. What initially enabled innovation has gradually made systems harder to evolve and, ultimately, harder to control.

The Operational Cost of Openness

More pressure, less control

Behind these architectures, operational teams face growing pressure.

Driven by customer-centric strategies and competitive dynamics, development teams are expected to deliver new services at an accelerated pace. This constant pressure to innovate can sometimes lead to compromises. Security practices may be deprioritized, and technical debt can increase as teams prioritize speed over resilience.

In some cases, developers are granted full or partial administrative rights, to accelerate their work. While this improves short-term efficiency, it also increases the risk of compromise. Other organizations will rather provide their developers with two laptops to to isolate tools and limit the potential spread of attacks. While this option fulfills seems to conciliate air-gapping and enables developers to have a specific environment with their Linx, it adds complexity in their workflows.  At the same time, developers often need to work across multiple environments and devices to isolate tools and limit the potential spread of attacks, adding further complexity to their workflows.

This creates a paradox: organizations demand both speed and security but often fail to provide the conditions required to achieve both.

When access leaves the office

Changes in working patterns have reshaped how developers access critical systems. According to a 2025 report, 32.8% of developers in France work partially remotely, while 18.1% are fully remote. This shift reflects a growing expectation for flexibility and autonomy.

While developers increasingly expect flexibility and autonomy, many organizations have struggled to adapt their environments to these new expectations. A significant share of developers now work at least partially remotely, which has led to a multiplication of access points to critical systems.  

To support this shift, companies deployed remote access solutions such as remote desktop protocols. However, these tools have not always delivered the expected levels of performance and flexibility. Solutions like VDI or RDS, often dependent on network quality or constrained by usability limitations, have sometimes led to frustration among users.

As a result, workarounds emerge. These unofficial practices may improve productivity in the short term, but they also introduce new vulnerabilities and reduce overall control over the environment.

Ultimately, this creates a double frustration for developers. They are expected to deliver faster, yet often lack the autonomy and tools needed to work efficiently and securely. This gap between expectations and reality becomes a source of risk in itself.  

When systems are no longer fit for purpose

A system not designed for how people work

This misalignment can be compared to a metropolitan transportation network designed for a different era.

In Paris, for instance, the metro system was historically built to connect suburban areas to the city center, not to enable direct movement between suburbs. As a result, traveling from one suburban area to another often requires passing through central hubs, increasing both travel time and congestion.

Banking systems face a similar challenge. They were not designed for the level of interconnectivity, flexibility, and distributed usage seen today. As digital services expanded and work patterns evolved, the architecture struggled to adapt, creating inefficiencies, friction, and new points of risk.

Just as urban planning had to evolve to better reflect changing usage patterns, financial institutions must now rethink their systems to align with how people actually work and interact with them.

The missing link: the logical separation of hardware and next-gen virtualization

One of the core limitations of traditional approaches lies in how environments are structured and isolated.

Historically, security has relied heavily on physical separation between environments. While effective, this model is increasingly difficult to scale in modern, fast-moving organizations. New approaches, enabled by next-generation virtualization, make it possible to rethink this model. Instead of relying solely on physical isolation, organizations can create multiple, logically separated environments on a single workstation.

For example, developers can operate within distinct environments on the same device: a corporate workspace and a fully isolated development environment tailored to their needs, with appropriate tools, such as a Linux-based setup, and security policies adapted to their workflows. By keeping resources locally allocated, these environments can maintain high performance while enforcing strict isolation.

This approach aligns with recommendations such as those promoted by ANSSI, which emphasize multi-environment workstations while acknowledging that physical separation is no longer the only viable option.

Ultimately, this shift enables organizations to resolve a long-standing tension. It provides developers with the autonomy they need to work efficiently, without compromising security or performance.

Conclusion: Virtualization is Back on the Market  

By opening their infrastructures through APIs and multiplying applications, financial institutions have enabled faster, more flexible, and more interconnected services. While financial organizations were transitioning, the way people work has evolved faster than the systems that support them. In the pursuit of accelerated innovation, they failed to think about the needs of the teams working on this new architecture.

Flexibility for application users, not for the ones who keep them running. And when remote work surged during lock down, even a sector that’s usually ahead in innovation found its developers relying on unstable and expensive VDI solutions, they still use today despite their well-known trade-off.

It is clear that the challenge is no longer to innovate faster, but to rethink how environments are built, enabling security, performance, and developer autonomy to coexist, while restoring the visibility and control organizations have gradually lost.  

That’s what we deliver with our solution.

Does it sound too good to be true? Let us show you how we do it.