The banking industry has undergone a significant transformation in the last decade. Today, for many consumers and businesses, banking is a primarily digital experience. However, it would be wrong to see this transformation as complete — for banking institutions there are technological opportunities that can help them become even more customer-focused and efficient. Together, these opportunities are paving the way for what is called “coreless” banking — cloud-based and asset-light systems built on composable elements that remove some of the demands and overheads of more monolithic approaches.
Coreless banking can underpin the future of the industry. Specifically, it will not only make it possible for banks to reduce the resources needed to build and maintain core technical systems, it will also help them to embrace a more open model of banking, allowing them to become part of a wider ecosystem of services.
However, while there are many advantages to coreless banking it can introduce complexity. This is why standardization is so important — without it, the promise of a thriving banking ecosystem is likely to falter. This is where the Banking Industry Architecture Network (BIAN) framework can help. A non-profit consortium of organizations from across the banking industry, BIAN wants “to promote and provide a common framework for banking interoperability issues” — in this blog post we’ll dig into what it is and how it can better support coreless banking across the industry.
What is coreless banking?
Before we get into why the BIAN framework can be so useful, let’s first take a look at what coreless banking actually is — and why it has the potential to define the way banking institutions operate in the future.
Coreless banking involves a shift away from monolithic and static technology systems to ones that are modular and composable. It bears some similarity to trends in commerce and content management where “headless” systems that allow for composability, change and wider ecosystem integration are increasing in popularity. However, in banking coreless is particularly significant as it represents a major shift in approach to how organizations interact with and serve their customers.
The table below provides an overview of the differences between “core” and “coreless” banking.
| Core banking | Coreless banking | |
| 1 | In-house and firewalled | Distributed with granular, domain-specific boundaries |
| 2 | Large monolithic and unyielding |
Modular and composable |
| 3 | Made of a large number of static and fixed point-to-point connections | Made of seamless, dynamic connections and relationships |
| 4 | Difficult to change as systems are embedded in legacy technology | Easy to change as it is free from vendor lock-in and supported by a thriving vendor base |
From a business perspective, coreless banking makes it easier for banks to focus on market differentiation. The idea is that by moving away from a “core” — a basic (monolithic) technological foundation that is largely identical to competitors — banks can focus resources on building products and experiences that are unique to them.
To a certain extent, many challenger banks have adopted a coreless approach. Lacking both the “burdens” of institutional and technical legacies, these banks are able to use third party services and commodity software to move at a faster pace and deliver unique products that deliver more value for customers. This removes those organizational dependencies that often constrain companies — you no longer necessarily need a set of engineers with specific system knowledge and can instead build using standards and recommended third party software.
Adopting a coreless approach, then, can give established banking organizations the ability to move quickly and meet market needs in the way that many of their more youthful competitors are already doing.
The four layers of coreless banking
Coreless banking can be understood as being composed of four specific layers:
Business capabilities and processes
Banking-specific technology capabilities (these include tools for things like risk profiling, customer prequalification, and authentication)
Cross-industry technology capabilities (thinks like accounting systems, communication and knowledge management tools and platforms)
Infrastructure
All four are important, but BIAN is specifically important in the context of the first two elements. We’ll look at those in more detail shortly, but let’s first look at exactly what BIAN is.
What is BIAN?
BIAN is, as mentioned in the introduction, a not-for-profit organization created to help the banking industry adopt a shared service-oriented architecture to improve interoperability and to better overcome the challenges posed by legacy systems.
There are many reasons why BIAN is so important in driving the banking industry forward, but in particular it can help organizations shift their focus to the ‘why’ of product creation — in other words, to addressing the needs of their customers. Instead of having to expend time and energy maintaining the “core” of their infrastructure and systems, by using BIAN as a foundation to move to coreless banking, banks can invest more time and resources into new services and products that address the needs of their specific customer groups.
How does BIAN help with the move to coreless banking?
BIAN’s work is particularly important in how it provides banks with guidance on both technology implementation and the organizational design required to successfully leverage such technology. As we’ve seen, these are the first two of our four layers of coreless banking.
In terms of organizational design — business capabilities and processes — BIAN provides a framework for banks to think through the ways in which various service domains should interact with each other. This is important because one of the challenges of moving to a service-oriented architecture is ensuring there are the relevant organizational structures in place to properly manage and leverage it.
In terms of technology selection, BIAN is particularly important because the needs of banking are often unique. Guidance or resources on how to make decisions about how to implement technology for things like risk-profiling, personalized finance and authentication aren’t widely available for the simple fact that they are deeply specific to the banking sector. By offering reference data models and API specifications, BIAN gives banks resources and standards that can ensure interoperability with partner ecosystems and enhances technology solutions’ effectiveness.
BIAN is not a silver bullet
Everything that BIAN has developed — and is continuing to develop — will help banks evolve their existing systems and processes to be decidedly more customer-centric.
However, it would be a mistake to see BIAN as a silver bullet solution to coreless, service-oriented architecture banking. Leadership teams inside banks still need to do the necessary work around the resources and tools put forward by BIAN to ensure that it can be leveraged effectively.
Here are just a few things that technology leaders in banks need to acknowledge if they are to embrace the opportunities of coreless supported by BIAN:
While BIAN’s semantic APIs are useful as reference APIs, organizations may need to introduce sub-qualifiers in service operations to align with their specific requirements.
When working with BIAN, a bank’s data elements will be mapped to what is called the BIAN BOM (business object model). This is, as the organization’s documentation explains, “a general accepted reference model of business capabilities that are needed to make a bank a bank.” For elements that aren’t covered in the BOM, banks must create their own custom model extensions.
It’s important to remain in-sync with BIAN releases — a failure to do so could disrupt execution timelines.
To use BIAN successfully, it’s also essential that banks have a solid understanding of their existing architecture and a clear sense of their roadmap for the future.
A better future for customers
By moving to coreless banking, banks will give themselves a better chance to remain responsive to the needs of the market and their customers — they will be able to evolve quickly and deliver new products and services that can address specific needs. With challenger banks seemingly able to move at pace, this is particularly important for established banking institutions — a legacy might matter when it comes to brand clout, but that’s certainly not the case when it comes to technology.
Such a change is undoubtedly challenging — indeed, that’s the very reason for BIAN’s existence. But if the industry can recognize the opportunities of a coreless approach to their systems and infrastructure we may begin to see many new exciting innovations across the industry. That has to be good for customers.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
