A Digital Transformation Journey in the Banking Sector
Featured image via Pixabay.
The banking sector is continually adopting modern approaches and API-led integration to optimize operations, add value and provide enhanced customer experiences. However, these approaches should be carefully evaluated to avoid risk and ensure security. With the pandemic and a number of new regulations, such as open banking, pushing the need for online/digitized services even further, digital transformation is not a one-step approach, but rather an agile iterative process.
From our experience, banks that take on open banking as a disruptive growth opportunity can go beyond fulfilling the regulatory mandate, entering new markets and creating new business models. They are also able to use this initiative to bring digital transformation to their organizations.
When building a digital transformation strategy within the banking industry, there are two main focus areas to consider: the actual business needs and the technological approaches that should be available to fulfill them.
Mergers and Channel Integrations
Consolidation of multiple banks into a single institution provides benefits such as lower operational costs, better-unified standards and help for geographically concentrated banks in expanding their coverage.
Technically, these plans require IT teams to look at existing infrastructure as well as the merged bank’s infrastructure. This is a tedious task, as we are looking at various legacy systems, vendor-specific applications and built-in processes — different protocols, message formats, business logic and technologies — that should work together seamlessly.
Stand-in Processing for Core Financial Services
Most online/mobile banking users are familiar with notifications stating that transactions made after a certain time are processed the next day. When considering online banking, electronic fund transfer (EFT) services (e.g., ATM, credit and debit) and mobile banking, supporting stand-in processing for key services (24×7) allows consumers to use banking throughout the day.
Most of the core banking systems are brought down, usually during night hours, to start end-of-day batch processing. Before the core banking system goes offline, it makes copies of the existing member/transaction files, which act as the basis for the period of stand-in processing. This allows 24×7 services to operate as usual. Once nightly processing is completed, updates of the copied files need to be processed back to the core banking system before it begins the usual processing.
From a technical standpoint, in order to support stand-in processing, a caching layer/store needs to be built in a dedicated system that can process data as well as ensure that there is no data loss. This calls for capabilities such as message transformations, file processing, data polling, reporting, data as services and integration with message brokers.
Open APIs and Standards
The introduction of open banking and additional regulation brought on the need to share data, such as account/payment information, with customer consent among other third parties such as financial institutions and fintech, regionally and globally. This data exchange occurs through secure APIs, giving customers control of their data while also providing better services. Even though regulations and compliance is not mandatory in some regions, APIs are a vital component in the banking sector as soon as you need to expose your services to various parties — especially to your customers.
At a minimum, APIs should be provided with the respective quality of services (e.g., using standard API formats such as Swagger, API security, rate limiting, API analytics, etc.) and should have capabilities such as API monetization, API marketplaces and API products. Business and operational insights gained through API analytics can play a bigger role in determining these expansions.
Reference Banking Architecture
A Reference Banking Architecture
A bank’s typical technology architecture comprises layers similar to those above. At the top, these can include mobile banking, ATM and POS operations and internet banking (this list can vary). At the bottom, all the internal applications and systems that define various banking processes can be found along with the data layer. The core banking system that is in use (e.g., Temenos, Finacle, Finastra, FLEXCUBE, etc.) can be connected to various electronic payment channels, such as EPS, and other batch-processing tools and databases. The connection between the internal data layer and the delivery channels is commonly maintained by a set of in-house solutions built using various technologies/frameworks, which support point-to-point integration.
This depicts a spaghetti architecture that is difficult to maintain and extend. When the number of applications and delivery channels increases, problems such as task duplications can lead to inefficiencies and reduce time to focus on strategic value-added tasks.
An API-led Reference Banking Architecture
Reference architecture with WSO2’s integration platform
The above diagram depicts the use of the WSO2 integration platform in a typical banking architecture. However, the following section discusses the core capabilities any integration platform should provide to bring about dynamic changes to every aspect of the business, such as converging divergent technologies, adopting agile strategies and becoming laser-focused on personalizing the customer experience.
When considering generic integration requirements, the ability to support enterprise integration patterns (message routing, transformation, correlation, incorporating with messaging systems, etc.) and support for various protocols and message formats (HTTP, HTTPS, JMS, REST, SOAP, FIX, ISO8583, FTP, JSON, XML, EDI, etc.) helps with seamless integration between the numerous systems that are involved in the banking landscape. It is also crucial to carefully design the data layer and to expose it securely as there are various databases and reports that are generated on a daily basis in a typical bank’s architecture. Consider exposing the data layer, which can be in various sources/formats (databases, spreadsheets, CSV files, etc.), as reusable standard services such as REST/SOAP will be beneficial from a maintenance aspect as well as to assist with seamless future innovations.
Also, there could be many proprietary (legacy/cloud) systems involved in various processes, which may not have standard service extension points and may support different messaging formats. For example, when considering core banking systems, although some may provide standard APIs for integration purposes (although some systems provide the APIs at a higher subscription or through different versions) many fall back to their own native protocols and message structures, authentication mechanisms (e.g., the use of OFS queries in Temenos). This becomes cumbersome, as there could be a lot of other internal applications that connect with the core banking solution. It is not scalable for each of these applications to maintain integration flows with the core banking system. This highlights the requirement of templated connectors in an integration solution, which provides service-type operations by wrapping any vendor-specific complexities so that the bank only needs to worry about the business logic.
As for the stand-in processing requirement, an intermediate caching layer can be built using the data services and the mediations incorporating any business logic that are developed. A preferred messaging system (e.g., JMS brokers) can be connected to this internal layer to ensure guaranteed delivery between the core banking layer and the middleware. It is also important to note the resync process that will need to take place once the core banking system is back online. At a high level, once online, the core banking system needs to pull any offline transaction-related data and update the internal systems and flag any such transactions to be processed.
Most banks do not have the required technology to implement these required tasks in their existing infrastructure. Streaming integration capabilities can be used in such a scenario by providing change data capturing (polling and listening modes) and advanced ETL (extract-transform-load). In addition, large file processing/transfer is an important aspect to consider when aligning the various backup mechanisms and batch processing operations that take place. The ability to visualize any operational insights/metrics around those operations, such as ETL/CDC, will be useful as a feedback loop to improve those processes and to troubleshoot.
While improving the integration needs with internal digital innovation, there comes a point where external parties would need access to certain services, which highlights the need to expose managed services responsibly (i.e., API management). Ensuring proper API security for an API-based approach is key as the exposed data is at high risk. Unless specified in a regulation, most banks follow standards such as OAuth-token-based security and OpenAPI specifications for REST APIs. In addition to API-level security, sufficient consideration should go to all aspects such as transport-level security, backend service-based security and various threat detection and protection mechanisms when implementing end-to-end authentication for the exposed services. Proper authorization mechanisms, such as OAuth2 scopes, should also be taken into account to make sure that the exposed service operations are only accessible to the intended consumers.
Once APIs are implemented with the necessary quality of services, the focus should be on the user experience provided to these external stakeholders in discovering, evaluating and actually consuming those APIs. Therefore an application developer-focused API store, various out-of-the-box SDKs, API documentation, rate-limiting capabilities and even out-of-the-box monetization can be used when a bank wants to generate revenue from the services they plan to externalize.
It is evident that digital transformation is a continuous process that needs to be addressed in a phased-out approach, allowing an organization to digitally evolve. Although the above discussion is not an exhaustive list of business and technical needs that arise in a banking landscape, they are quite common across the globe and are the fundamental starting points of a digital transformation journey.