The core banking systems currently in active production at a meaningful number of Central European banks were installed in the late 1990s or early 2000s. They are stable, thoroughly understood, and going nowhere. Not because the institutions lack the budget or the will to modernize, but because core banking replacement is a multi-year, multi-hundred-million-crown undertaking that carries significant operational risk for an institution whose primary obligation is stability.
We work with banks and insurers across the Czech Republic, Slovakia, Austria, and neighboring markets. The technology reality at most of these institutions is not what vendor slide decks describe when they talk about open banking and API-first architecture. It is a production environment where the core system is twenty years old, exposes no REST API, and runs on infrastructure that predates virtualization.
That is not a criticism. Those systems process millions of transactions accurately, day after day. The goal is not to replace them. The goal is to build an effective automation layer on top of them that works within their constraints.
The API Assumption and Why It Fails Here
The standard advice from process automation vendors assumes API access to the systems you want to integrate. Modern RPA platforms have moved strongly in the direction of API-first orchestration, and for good reason: API integration is more reliable than UI-layer integration when available. Version stability, structured data contracts, and documented error responses make API-based automation significantly more maintainable.
But Central European banking environments frequently cannot meet the API assumption. The older core banking platforms that remain dominant in the region do not expose modern API surfaces. Some offer SOAP-based web services that were added in incremental modernization projects, but coverage is incomplete and varies by installation. Many institutions have direct database access to their core, but that path is constrained by regulatory requirements around auditability and segregation of duties that make database-level automation difficult to justify to a compliance team.
The organizations that have successfully automated back-office processes in these environments have done so by accepting the UI layer as the integration surface and building automation that is durable at that layer.
What UI-Layer Integration Actually Requires
Reliable UI-layer automation in a legacy banking environment is different from automation built against a modern web application. The legacy interfaces in question are often terminal-emulator-style thick-client applications, older Windows-native applications with custom UI frameworks, or web applications running on browsers with specific version requirements. None of these behave the way a modern web form does when approached with standard automation tooling.
The specific requirements that experience has shown to matter: the automation needs to handle synchronous screen waits correctly. Legacy systems often present the user with an intermediate screen or status indicator between operations that has no direct equivalent in modern systems. Automation that does not account for these correctly either races ahead and misses data or waits too long and times out. The acceptable wait tolerances and the indicators that signal completion need to be documented as part of the process definition, not discovered at runtime.
Character encoding is a consideration that comes up repeatedly in Czech and Slovak environments. Systems built for the Central European market need to handle characters correctly. An automation that transfers data containing Czech-specific characters across systems needs to be tested on real data that includes those characters, not on generic test data that only contains ASCII.
Session state management in legacy systems is also more complex than in stateless web applications. An operator who steps away mid-process may return to a different session state than expected. Automation that does not handle unexpected session states gracefully will fail in ways that are hard to debug and hard to explain to an operations team.
The Change Frequency Question
A common concern about UI-layer automation is fragility: if the interface changes, the automation breaks. This concern is valid in environments with frequent UI updates. In the legacy core banking environments we see across Central Europe, it is largely theoretical.
A core banking system installed in 1999 and still running in 2026 has not had its UI substantially redesigned in twenty-five years. The vendor may have gone through two acquisitions. The software may have received security patches and compliance updates. But the operational interface that a reconciliation operator uses to enter data is, in many cases, essentially the same interface that was delivered with the original installation. The change frequency is low enough that UI-layer automation maintenance cost is manageable.
The meaningful change events to watch for are: vendor-mandated upgrades that affect the UI (these are typically announced months in advance), internal configuration changes to screen layouts (which require change management controls to catch), and transitions to a hosted model where the system provider controls the update cadence. The last category is where the change frequency assumption needs to be reassessed.
Integration Without System Replacement
The framing that resonates with operations leaders at Central European banks is "integration without system replacement." The institution has invested decades in its core banking system. The operators know it. The compliance team has mapped all its behaviors. The risk team has approved its operating model. A modernization project that requires replacing the core upends all of that work and introduces years of parallel-run operational risk.
What those leaders want is a way to add efficiency and automation capability on top of what they already have, without creating a dependency on a future replacement project. UI-layer orchestration delivers exactly that: it adds a layer of automation that interacts with the existing system in the same way a human operator does, produces structured audit logs that can be fed to downstream reporting systems, and handles exceptions in a way that keeps the operations team in the loop.
The institutions that have made the most progress with back-office automation in this environment are not the ones with the most modern core systems. They are the ones that stopped waiting for the modernization project and started building the automation layer on top of what they already had.
What Karolina and Martin Have Observed
Our Head of Process Engineering, Karolina Dvorakova, spent several years in insurance operations consulting in this region before joining Pointee. Martin Skalicky, our CTO, built integration connectors between legacy core systems and modern tooling for most of his career. The consistent finding from both of their backgrounds: the technical constraint is rarely what blocks automation projects. The organizational constraint, usually the absence of a structured process definition before automation development begins, is what makes the technical work harder and slower than it needs to be.
A bank with a legacy core system and a well-documented set of its back-office processes is in a better position to automate effectively than a bank with a modern core and poorly defined processes. The technology constraint is addressable. The process clarity constraint is the work that has to happen first.