Modernize without rebuilding the bank from scratch.

What the market is asking for

The budget projected by the Febraban 2026 survey shows the scale of investment in technology. The figure does not prove a return, nor a preference for any specific architecture. The editorial question is a different one: how much of this effort increases the capacity to deliver the next product?

The pressure builds when a business change requires updates across multiple channels, integrations, and operational routines. A new credit term or a new access condition stops being a localized decision and ends up competing for a delivery window across the entire organization.

Reference: Febraban · Banking Technology Survey 2026 ↗

Choose a business boundary

A useful slice might be simulating an application, verifying identity or formalization. It needs an input, an output, an owner and an observable outcome. Choosing a capability just because it's easy to extract can produce a new API without improving anyone's work.

Consider an institution that presents different conditions in the app, the partner portal, and at the desk. Centralizing the calculation in a capability with an explicit contract creates a single place to discuss the rule. The channels remain distinct, but they consume the same responsibility.

Coexistence is part of the solution

A migration needs to define where the authoritative data lives, which operations can be retried, and how to compare responses. During the transition, running calculations in parallel can help surface discrepancies before routing real traffic. Operations that move money call for extra care: retrying a call must not repeat its effect.

A modular boundary does not eliminate coupling on its own. Versioning, failure handling and compatibility need to be agreed with consumers. When a capability gains many users, a poorly governed change can amplify the impact instead of reducing it.

When to share — and when to preserve the difference

Reuse exists when two products need the same responsibility and accept a shared contract. It is only superficial similarity when identical names hide different rules, lifecycles or requirements. Forcing both into a single implementation tends to turn parameters into hard-to-understand exceptions.

The idea is to share the foundation while keeping the context explicit. Banking, credit and receivables can reuse identity and documents without sharing the same approval policy. The architecture needs to allow for that difference.