Anatomy of ABS: In-house development versus architectural dependency

Sardor Khujaev, city — Tashkent, team lead of the ABC development team at Kapital Lab, Uzum Technologies, LinkedIn

1. The Illusion of the “Box”

When a bank signs a contract for a vendor-based Automated Banking System (ABS), it is convinced that it is purchasing a product. Three years later, it becomes clear: it has purchased dependency.

In the first two years, the system behaves predictably. Then the bank begins to grow — and the friction surface with the core increases faster than the team can control it. Not because the vendor is bad. But because a classic ABS is built as a vertically integrated monolith: business logic, storage, UI, and workflow engine live in a single database schema with a level of coupling such that any change pulls a chain of non-obvious consequences.

The phrase “flexible configuration” in most cases means flags in configuration tables controlling monolithic procedures. This is not flexibility — it is managed chaos, the cost of which grows exponentially with each year of operation.

2. Time-to-Market as Structural Divergence

The change delivery cycles of the vendor and the product development cycles of the bank exist in different temporal dimensions. This is not a management issue or a priority issue — it is an architecture issue.

A monolith does not allow you to change one procedure without checking everything else. This is an honest position of a responsible supplier. But for a bank that wants to test product hypotheses iteratively, such divergence becomes a structural limitation on growth.

This is where the conversation begins about what the bank should build itself — and exactly what.

3. Interface as a Point of Loss of Control

There is a problem that is discussed less than Time-to-Market. This is the interface.

Vendor systems go through changes in UI paradigms: from heavy desktop clients to various generations of web interfaces. The main pain here is not the fact of changes themselves — any frontend requires user adaptation. The problem is who holds control over this process: when it changes, in what direction, and at what speed.

As long as the UX layer belongs to the supplier, the bank reacts — instead of managing. This is a fundamental difference, and it is more expensive than it seems at the start.

4. Architectural Choice: Between Two Fires

When the conversation turns to reducing dependency on the vendor core, the first reflex is “let’s break it into microservices.” This is a understandable desire. And quite expensive, if you choose the wrong moment.

The real work of an architect in fintech is not choosing between “leave everything as is” and “rewrite everything correctly.” It is the ability to choose the right point of application of effort at the right moment. A mistake in this choice costs months of work and operational risks — regardless of which direction the mistake was made.

If you have a similar task, the conversation should start with an architectural audit of the existing architecture.

5. Stability Under Load: Where Problems Hide

At a load of 1800 TPS, problems appear where you don’t expect them.

When the integration layer reaches full load, an unexpected weak point is often not the logic itself, but the junction between components. Connection pools, timeouts, hung sessions in the database — all this begins to manifest precisely when the system is working at its limit. And this is usually not a task for one team: the boundary between the bus, the application, and the database requires joint tuning from both sides simultaneously.

The same story applies to the stability of the database itself. Integration code under load can create effects that are invisible at low traffic and critical at high traffic. Execution plans, shared memory, optimizer statistics — all this lives its own life, and without strict control, it will “fire” at the most inconvenient moment.

This is not a guide — this is just a list of places where we have already been bitten.

In Conclusion

A vendor-based ABS is neither a problem nor a solution. It is a given with which most banks in the region work. The question is not about the quality of the core — the question is whether the team can build architectural boundaries around it that return the bank control over its own speed.

The complexity is not in knowing the right tools. The complexity is in choosing the right point of application of effort at the right moment. This comes with experience working specifically in such systems — and this is exactly what distinguishes an architectural solution from an architectural intention.