The raw -- yet burgeoning -- potential of coreless banking
While coreless banking is still a novel concept, it shows strong potential to liberate banks from the rigid software systems that have dominated the industry for decades.
Like others in the finance industry, banking institutions are renowned for their reliance on large, decades-old software systems that, while operational, still suffer from the issues associated with overly rigid, monolithic application architectures. Despite the widespread availability and active adoption of innovative design approaches like microservices and serverless computing, the risks of falling victim to crippling security breaches or suffering the consequences of violating unforgiving financial data management regulations have left many unwilling to pursue new types of architecture design.
Fortunately, there's a burgeoning initiative known as coreless banking that aims to use innovative design approaches like microservices to build scalable and efficient software for use in the financial services industry. While still in its formative stages, the concept shows a lot of promise when it comes to desegregating overly coupled, centralized banking software systems while keeping essential reliability and security faculties intact.
Embracing coreless banking, however, requires developers to think carefully about technical details, such as how to manage APIs and how to segment domains within software ecosystems. Let's look at the concept of coreless banking, how it works and what its potential drawbacks might be.
What is coreless banking?
Coreless banking aims to make the various components of traditional banking applications more independent. This means developers working on banking applications can execute isolated updates or deployments without affecting other application services, components or operations. It also means that if one part of the application goes down, it's less likely to take the rest of the applications with it. Ultimately, the goal is to free financial services companies from their longstanding dependency on legacy infrastructure and application development models, ultimately unlocking new levels of scalable, efficient and cost-effective software.
The "core" in coreless banking is a reference to the centralized software environments and systems traditionally used to govern operations in the banking industry -- a practice that dates back as far as the 1950s, when finance and banking software first emerged on a major scale. Although centralized design might have been the most practical approach at that time, its codification as an indispensable practice left many banks reliant on legacy mainframes and outdated software management systems that can be arduous to maintain and painful to extend.
Where traditional banking apps would need to interact with a centralized mainframe to perform user logins, account information queries or other basic operations, coreless banking apps are designed to do things like track account details and manage authentication processes completely unaided by a mainframe or any other centralized system. Of course, a coreless banking system might need to query a database that stores user and account information, but it could, theoretically, host that database anywhere.
Technical elements of coreless banking
Coreless banking is much more of a concept than a prescription of technical specifications or specific architecture design patterns. However, one of the most straightforward ways to build scalable applications with loose coupling is to introduce a microservice-based architecture. Microservices can often provide the same functionality as the legacy applications they replace, but they add the benefit of greater service autonomy and eliminate reliance on centralized infrastructure and services.
Of course, implementing a reliable coreless banking system correctly depends on more than just microservices. It also requires strong API management, organized automation and meticulous domain segmentation. Let's review the details behind the following three major elements of coreless banking.
API management
Distributed services depend heavily on APIs to facilitate data sharing and to relay requests. As such, developers must manage APIs carefully to ensure they provide both the visibility and comprehensive security controls necessary to handle sensitive banking operations. Well-managed APIs make it possible to handle tasks like authorizing transactions or maintaining audit logs. This also means transactions can be managed at the API layer of the stack rather than within each individual application, allowing for more efficient development processes.
Automation
To operate as efficiently and reliably as possible, coreless banking applications should be fully automated. These applications should be able to scale seamlessly, adding or removing microservices as needed. Developers should also have automated application delivery pipelines in place to quickly deploy new application features.
Domain segmentation
Coreless banking requires architects and developers to carefully determine how application functionality and access to information is regulated across the various APIs and application services that will inhabit the organization's software system. For example, developers may want to segment account information lookups from account changes so that those who have access to bank account balances can't also move money out of those accounts.
While boundaries between domains aren't always easy to determine, the non-negotiable need for airtight security makes domain segmentation one of the most important factors to consider when implementing coreless banking architecture.
Drawbacks and challenges of coreless banking
Coreless banking has the potential to transform the way financial services applications operate by freeing banks from legacy infrastructure.
Coreless banking has the potential to transform the way financial services applications operate by freeing banks from legacy infrastructure. However, there are some potential downsides and tough challenges associated with coreless banking that require careful attention from architects and developers, which are reviewed below.
Lack of established standards
Coreless banking is currently more of an abstract development concept than an established industry practice. Although some vendors and industry groups like Red Hat and BIAN actively promote tools and methodologies that enable coreless banking, there's currently no defined way for developers to remodel a bank's existing legacy infrastructure into desegregated applications that align with both operational and industry regulation requirements. This lack of guidance and established standards for open banking initiatives means organizations are simply left to experiment with coreless banking architectures to determine if the approach will work for them. Unfortunately, many of those running bank software are much too preoccupied with maintaining day-to-day operations to dedicate time to this type of experimentation.
Alignment with overall business goals
Playing off the lack of industry acceptance, developers who spend time figuring out how to overhaul a bank's software architecture might not obtain much support from the business side -- despite the potential to improve business operations and reduce security risks. For this reason, developers should limit initial experimentation with coreless banking to lighthouse projects aimed at low-stakes applications. These can serve as good proofs-of-concept to have on hand once the business side finally becomes open to the idea of revamping centralized legacy systems.
Development resources
Legacy banking systems are large, complex systems written in languages like Fortran or COBOL, which may be unfamiliar to newer developers. Also, bank software has traditionally revolved around the use of CQRS to separate read operations from write operations and to reduce the chances of accidental data modification. Unfortunately, modern microservices architectures and APIs don't always place a premium on CQRS patterns. This means developers working on coreless banking will need to become very familiar with things like Fortran, COBOL and CQRS to build applications that incorporate the principles and purpose associated with these longstanding languages and patterns.
