Composable architectures in financial services – The basics

Background

Development of IT applications for banks and insurance started a long time ago and happened in-house, using what is now deemed as legacy technology. Designs were centered around batch, on-line programs displaying character screens and reports. These solutions were, naturally, monolithic with data, function and presentation being tightly intertwined. Many organizations still use these use these systems and struggle with digitization, loss of critical knowledge due to a retiring workforce and rising costs for maintaining the application landscape.

During the late 1990’s and beyond, we started seeing the emergence of COTS (commercial off the shelf) software solutions. These have been upgraded over the years. They today leverage more modern technologies, provide API’s and have an improved layered architecture internally. Many of them are, successfully, separate into different modules from a functional perspective. However, these packages are still generally broad and suited for end-to-end implementations that require embarking on massive transformation journeys. 

What we now see is the emergence of composable architectures and COTS software solutions which are aligned with this architectural thinking. These types of architectures and solutions are today starting to become commonplace with Fintech’s and smaller institutions, globally and in the Nordics. We are also starting to see adoption among larger institutions. This type or architecture and solutions come with benefits and drawbacks, which we will explore further. 

Composable architectures and solutions

There are several drivers behind the emerging trend towards composable architectures and solutions. One is the ever-present need for hyper-digitization requiring real time access to data via API’s including but not limited to Open Finance. We also believe regulators will require this type of real time access to data in the mid-term, rather than periodic reports. More important is a need to de-duplicate functions, moving the actual architecture closer to a normative reference architecture. For example, there should only be one deposit and lending ledger regardless of financial products rather than having many similar overlapping core systems. Such an architecture will simplify the participation in value chain disruptions, banking-as-a-service and similar. 

It is obvious that moving to such an architecture is a major endeavor, with all the usual risks associated. We prefer to see it as an architectural ambition and blueprint, to be leveraged over time – especially for larger institutions.

We see a number important and attractive benefits associated with a composable architecture and solution set.

• Leveraging modern, cloud base solutions enable scalability, cost effectiveness (if done right) and access to the most modern, high-productivity tooling for development organizations
• These solutions are fully API enabled, operating in real time internally as well as externally.
• As the solutions are typically function specific rather than broad and wall-to-wall, such an architecture reduces vendor lock-in 
• For the same reason, transformation journeys can be structured in a different manner – taking functional steps one at a time, rather than a big bang approach
• De-duplication of functionality in the architecture promises reduced life-cycle cost of ownership
  

There are of course also drawbacks with this type of architectures, which need to be addressed at the design stage and considered in decision making.

• The solutions available today are, very generally speaking, better abled for use in simpler use cases from a product standpoint – you would not use them for, say, global commercial lending.
• Some solution providers are quite small, and proper due diligence is required for larger institutions.
• Almost all solutions providers are cloud based, and careful considerations are important to avoid unexpected cost increases due to cloud consumption.
• Creating a real time architecture with multiple solutions interacting with each other, as well as legacy solutions is highly challenging, whereas a proper data and integration fabric or platform is required – we will explore this in the next post.
  

In conclusion, there is a lot of interesting developments happening. Retail banking is, in our estimate, 5+ years ahead of insurance in this but we are seeing development in this sector as well.

Our next post will talk about the data and integration fabric or platform which is required – stay tuned!