By Sayon Deb
The degree to which community banks can innovate is largely dependent on the state of their core banking platforms. Unfortunately, legacy architecture in most core platforms limit the ability to support innovation. Analysts estimate that more than two in five U.S. banks still run their core banking processes on legacy back-end systems designed nearly four decades ago.
Legacy architecture once built for stability and reliability now generates pain points for bankers: multiple disparate systems operating independently, hundreds of applications that rely on point-to-point integrations, and asynchronous front-office and back-office processes, among others. This arrangement results in nearly unscalable systems and operational inefficiency. To make matters worse, maintaining these systems is expensive, with banks spending upwards of 80 percent of their IT budgets on simply preserving their technological status quo.
Each of these options carries its own set of benefits, risks, costs, complexities, and outcomes. The optimal for a given bank is driven by the current state of its tech stack, business objectives, and the unique constraints on its operating model, including organizational risk tolerance.
What is middleware?
For institutions that don’t want to replace or convert their core systems but instead wish to extend their core systems’ functionality, middleware solutions can help bridge legacy technologies with new applications. It’s becoming increasingly popular among banks that have substantial investments in legacy core infrastructure that want to mitigate the risk of change. Adding a middleware layer can also better prepare a bank for an eventual migration away from the legacy core.
The API-led middleware acts as a translator between a financial institution’s core banking systems and the various customer-facing systems of engagement that utilize business logic and data stored in the core banking platform, whether for internal business applications and dashboards, a fintech partner’s platform, or the bank’s own customer interfaces. The middleware path to core modernization is gaining attention from smaller institutions as it carries a relatively lower price tag and risk potential, while limiting changes made to legacy core systems.
Using middleware in the banking tech stack can give rise to three key benefits:
- Reducing reliance on legacy core to deliver products faster and make future conversions easier
- Building a single source of truth for customer data, leading to better customer experience
- Fostering partnerships with fintech companies
The use cases supported by middleware are numerous, from deposit operations and contact center management to branch activities and back-office operations. API-based middleware solutions are flexible and can be applied broadly across any banking function that would benefit from rapid access to customer or internal data.
Reducing reliance on a legacy core
By integrating a bank’s core and other back-office systems to an API-based middleware platform, banks can gain rapid access to their data—with less complexity and less staff time—generating new opportunities for revenue growth. Banks looking to respond to rising competition and customer expectations for on-demand digital self-service understand that speed-to-market is crucial and that they can’t rely on their legacy systems for fast product delivery.
Many institutions have found themselves with ROI-positive projects in the pipeline that are constrained by a lack of ready-access to internal business logic. Banks often face a protracted timeline in getting approval from their core provider for third-party fintech access. Without needing to rely directly on the core to launch new apps, middleware equipped with business logic makes it faster for a third-party service to get connected to the core data without waiting on a legacy core vendor to build the connection.
Adding a middleware layer also can better prepare a bank for an eventual migration away from the legacy core. By connecting applications through the middleware first, the bank reduces its dependency on the legacy core system. Eventually, the legacy core can be replaced by connecting a new core to the middleware, without reconnecting each application to the new core. Moreover, the bank can do so without experiencing downtime across all other front-end systems that have integrated to the middleware—because they’re reliant on the middleware layer, not on the core.
Building a single source of truth for customer data
Banks can use middleware platforms to unify disparate sources of customer and internal data into one platform forming a single source of truth to build better products and customer experience. Despite its promise of being a centralized repository of data, legacy core systems have been decentralized for a very long time, with multiple sets of customer data stored in different places and in various formats. Banks can use APIs and the middleware integration layer to help deliver a 360-degree view of the customer across lines of business for a seamless, connected experience across channels, such as mobile apps, in-person locations, contact centers, wealth, and marketing.
Banks consistently identify integration as the main obstacle to meeting their customer experience needs. Ideally, customers should be able to transact easily online with real-time updates across all back-office apps. But in reality, many bank customers have a disparate experience on digital banking channels; for example, because their credit card and debit card data are stored in two different places and they need to log into two different apps. Another example would be if the customer changes their address, but that change is not reflected in real-time across various back-office systems, including the core platform. As a result, the customer experience suffers from these back-office inefficiencies.
Fostering innovation and third-party partnerships
APIs are also gaining traction in financial services as an enabler of bank-fintech partnerships. In 2019, Capgemini found that a majority of banks globally use APIs to connect with fintech firms as part of their business strategy, and the pace of external API sharing is accelerating, with two-thirds of banks saying they currently share APIs with their partners and more than a quarter plan on sharing APIs within a year.
Banking leaders welcome a shift away from competition and toward collaboration with fintech companies. Survey data collected by Finextra in 2019 found that 81 percent of banks globally view collaborating with fintech partners as the best strategy to achieve digital transformation. Among U.S. financial institutions that sentiment is even stronger: 97 percent of banks surveyed for a 2019 Finastra study agree that collaboration with third-party entities and fintech firms will serve as a driver of their businesses’ successes.
By connecting with a range of external players including payment cards, investment and brokerage firms, and fintech companies, banks can explore new revenue stream opportunities or offer personalized experiences to their customers. These types of connections are supported by partner APIs, which represent roughly 20 percent of banking APIs, according to the 2020 McKinsey survey, and are used externally to support integration with business partners. The survey also showed that banks have plans to double the number of partner APIs by 2025.
In addition to supporting bank-fintech partnerships, middleware can enable external facing activities for banks, including banking-as-a-service, or BaaS, and third-party risk management.
BaaS models—the provision of banking products and services through third-party distributors—are emerging as yet another use case for middleware-enabled third-party partnerships. In this scenario, banks act as modular platforms that supply core banking functions which fintech firms source to build their own financial services. The role API-based middleware plays here is similar to how middleware platforms enable external connectivity or partnerships with fintech providers generally. The distinction, however, is that the bank gives up some control over the customer journey and instead focuses on back-office activities. Playing the role of the sponsor bank for a fintech won’t be suitable for every institution but can be a sound strategic move for some institutions.
Middleware can also play a role in helping banks conduct their third-party risk management. Historically, TPRM programs focused on point-in-time assessments such as annual due diligence and review processes. As the financial services environment evolves and becomes more dynamic, however, real-time observability is mission critical. Banks can contract with third party companies to perform activities on their behalf, but reputational, financial, regulatory and operational risks all remains with the bank. Just as banks establish key performance or risk indicators, banks can establish triggers and metrics to monitor change in their fintech relationships.
With middleware sitting in the data flow between the bank and its external partners, banks can build out risk management applications to actively monitor transactions. This approach puts a greater emphasis on information gathering on a regular cadence rather than an annual checklist exercise. A middleware-based TPRM application can help monitor risks as they emerge based on critical risk factors identified during the due diligence phase of onboarding a fintech partner.
Middleware is not a magic bullet. While banks can use middleware to temporarily prolong the lifespan of their legacy core systems, the reality for many banks is that an eventual core replacement is likely unavoidable, especially given the pace at which technology is advancing. The long-term solution for most banks in all likelihood involves the implementation of cloud-based core banking platforms, but a middleware solution can buy time to make that critical investment.
Sayon Deb is a senior director in ABA’s Office of Innovation. He is the author of “Exploring Banking Middleware Solutions,” a new report from the Office of Innovation, from which this article was adapted.
