The Path To Delivering Fluid Organizations

July 2026

Today, financial services institutions (FSIs) are juggling opportunities—and challenges--arising from the expanding landscape of AI, and agentic AI in particular; distributed ledger technology (DLT); alternative/crypto currencies, and further technologies. So, no surprise, there is a lot of talk about new mind-boggling architectures that will help FSIs to create the foundation for AI, DLT, and emerging financial products and technologies. Yet while there’s lots of chatter about the future of the financial services industry, today’s reality is different. 

Many FSIs lack the required technology foundation to successfully leverage all these new capabilities. And compounding the foundational elements improving data quality and reducing technical debt have been priorities on the FSIs to-do-list for decades, yet most have kicked these two cans down the road.  The result? FSIs are simply unable to implement business-critical technologies quickly and efficiently that will enable them to swiftly meet these and other new business challenges. 

Let’s avoid any inflated discussion whether financial services firms need quick adaptation of new technologies or transformation of the entire architectural landscape. It’s more a play of words than a genuine “either-or”. Let’s focus instead on how FSIs can achieve the hyper-flexibility that is necessary to remain successful in the future’s business world. 

The fact is that FSIs now depend on architectures that can support today’s rapid pace of business and technology change while still working with legacy technology dependencies that many can’t extricate their businesses from. Today, there is, at best, a very small minority who can accomplish this across their entire application landscape. Most struggle to cope with disentanglement, integration, and even making simple changes at business speed. 

Because this change won’t stop anytime soon, FSIs’ architectures need to withstand continuous change. This is why the Angry Rabbit Group has started talking about Evolutionary Architecture in 2024 and described the detailed concept of the Evolution Hub (or Ev hub) in a November 2025 webinar. Right now, there many, maybe too many discussions, about what technologies and what vendors will replace core banking or core insurance applications. However, both are not only an application, but the embodiment of the FSI’s business. 

Evolutionary Architecture

Whether core banking and insurance apps as we know them today will disappear (I have some doubts) or not, it is now a good time to discuss how an architecture can support continuous business and technology change. Let’s revisit the concept of the Ev hub. In a nutshell, Ev Hub’s design focuses on multi-layered abstraction that delivers loose coupling and enables continuous change (see Figure 1). The aforementioned article about Evolutionary Architecture provides more details.

The Evolution Hub

The Ev hub is a logical, a conceptual architecture element, not a physical one. It may be a central or a distributed hub or even no hub at all. As a logical architecture element, it “sits” between requesting and serving and served systems respectively. A security layer protects the processing chain itself (see Figure 2). The Ev hub itself has four major building blocks:

1. The Ev Nucleus. It has three key functions: First, it handles incoming and outgoing communication service requests and responses of preferred types, such as APIs, streams, and events. Second, it translates the payload data into an (optional) Ev hub internal data model if necessary and vice versa – some may say this is a canonical data model.* Finally, it forwards service requests to one or more processing systems; combines responses from multiple serving systems into a single response; and then returns the response to the requesting, now served, system.
   
   
2. Integration. As long as a requesting or serving systems uses the preferred communication types that the Ev Nucleus supports directly, there is no need for this building block. If not, this building block allows embracing other systems, especially legacy systems that need an integration adapter, for example. A tech team can either build Ev hub-specific adapters or reuse and modify existing integration adapters, for example. While not mandatory, this element of the Ev hub is where today’s and tomorrow’s legacy system can become part of a vivid application landscape.
   
   
3. Flexibility Enhancements: The Ev hub data store helps better accommodating multi-system real-time information requests. For example, if non-real-time-capable applications are repeatedly involved in a real-time information request, the data store can act as a cache for selected non-real-time information. Configurable routing information enables the Ev hub to determine which application systems need to get involved in processing this kind of request. It also helps a tech team to quickly change routing configurations if a change in the application landscape impacts processing. This is how the Ev Hub helps manage tech debt.
   
   
4. Functionality Enhancements: This design element is potentially very broad and rich. It is the place for custom development and off-the-shelf plug-ins. Functionality enhancements are the home for product configuration, limits management, revenue management, billing, real-time-data across modern and legacy systems, and many more business capabilities that stretch across multiple back-end systems of a given FSI – and its business partners--in any given ecosystem. Functionality Enhancements will strongly build on Flexibility Enhancements.

An Ev Hub Example

Let’s use a simpliefied example to explain how a payment transaction would work in a banking environment with an Ev Hub-based architecture (see also Figure 3):

1. Payment initiation: A retail customer initiates a payment transaction via the mobile phone.
   
   
2. Request generation: An engagement platform sends a payment request to the Ev Hub. Here, we have need to consider at least two options:
   
   
3. Limits option A: The bank uses a dedicated limits management. The routing table tells the Ev Hub that it needs to check with the limits system first. This system would either approve or reject the payment request.
   
   
4. Limits option B: The bank uses an Ev Hub limits plug-in. This means it would leverage the multi-system request capabilities of the Ev Hub to collect limits data from one or many back-end solutions and data from the Ev Hub data stores to serve the limits request. Thus, the Ev Hub would establish what we call a context-aware real-time (CART) request to determine the fate of the payment transactions.
   
   
5. Payment request: The Ev hub would send a request to the payments systems, if the payments transaction had been approved.
   
   
6. Payment execution: The payments systems would typically forward the payment request to systems outside the bank.
   
   
7. Account update(s): If the payment transaction was successful, the Ev Hub would also send requests to the involved core banking system(s) to update accounts; and notify the engagement platform (not illustrated in the figure).
   
   

This example shows that the Ev Hub can not only handle multiple payment scenarios. It also illustrates that the Ev Hub can isolate the impact of a transition from an existing limits solution to a new one (be it via the Functional Enhancement of the Ev Hub or a third-party solution). The Flexibility Enhancements would carry most of this change’s impact.

The Ev Hub Delivers Fluid Organizations

Once more, continuously changing banking business models need fluid organizations. Effective, fluid organizations will use evolutionary architecture to:

• Rapidly and seamlessly support organizational change, enterprise-wide new business capabilities, changing information needs, changing data ownership, merger and acquisition technology integration, and expansive—and complex--partnerships.
  
  
• Build on the Ev Hub concept to rearrange their application landscape; add or update business functionality, provide and update data across the enterprise, and manage complex data inquiries and analytics.

How to move forward

When introducing the concept of the Ev Hub into their organizations, FSIs need to clearly distinguish between modern and legacy architectures during their journey toward evolutionary architecture. Figure 4 shows likely first steps in an environment leading to evolutionary architecture while adding support of different business objectives during that journey.

Like many overviews, this table is not fully self-explanatory. Let’s have a look at a few of the built-in assumptions:

• No one-offs: The one-time integrations in Step 1 are not one-offs, but will empower legacy apps to contribute to evolutionary architecture.
  
  
• CART: Data stores can allow legacy data sources to become part of context aware real time (CART) information environments, even in batch-oriented legacy environments.
  
  
• EV security: It only comes in Step 2. However, after initial testing, broad and rich security capabilities become mandatory. At a minimum, this means the Ev Hub becomes part of the enterprise’s security mechanisms.
  
  
• New types of business apps: Adding Functional Enhancements can deliver financial services functionality across a host of back-end systems, be it product configuration, revenue and billing, or limits. Our example has shown that instances of the hub can potentially replace certain data-focused systems such as limits. These plug- ins have the potential to create entirely new types of business applications.
  
  
• Configuration, not project: With routing information and data models, the true potential comes into life. Major business process change, working in partner ecosystems, and serving new information needs will become continuous--an architectural configuration rather than a year-long transformation project.

With the Ev Hub, financial services institutions become fluid organizations, enabled to innovate at scale and thrive in a world of new business models. If you want to learn more, please let us know: GetInTouch(at)AngryRabbitGroup.com.

* A short explanation: A canonical data model is a standardized, technology-independent representation of business data that serves as a common language between different systems in an organization or across organizations. Instead of creating a separate data mapping between every pair of systems, each system maps to and from the canonical model.