By D.J. SeeterlinThe selection of a core processing vendor is a significant event for any bank; the core vendor is often the second largest non-interest expense behind employee salary and benefits. These vendor relationships are long-term partnerships that start with a multiyear agreement and can span decades. Core banking software is the central nervous system that determines the bank’s ability to meet the evolving needs of its customers, develop new products and services and define staffing resource needs and the end customer’s user experience. The mere thought of a core conversion strikes fear in the heart of even the most fearless bankers due to both the complex nature of each technology ecosystem and the sheer effort required to perform a conversion—not to mention the impact the decision will have on the bank’s future capacity and capabilities. It is critical for bank customers, employees and shareholders that banks get a strategic core decision right.
As a member of ABA’s Core Platforms Committee, I’ve learned that the core industry offers multiple solutions and multiple products from a myriad of vendors, some large and well-known and many less familiar, ranging from regional cores to startups. The first step for a bank to establish a successful partnership is to clearly define its own go-forward core strategy, which should align with its business strategy and corporate philosophy. Banks’ business strategies can vary widely; they may choose to prioritize growth (organic or merger), product differentiation, speed to market and staffing investments. A bank that wants to differentiate itself with a best-in-class digital platform has a very different strategy from a bank that is focused on traditional in-person loans and deposits. Similarly, a bank that chooses to invest in building a technology staff that can support fintech partnerships has an entirely different approach from a bank that prefers to partner with an established full-service technology firm.
- Speed to market. New products and unique solutions come from a diverse marketplace. Working with a diverse ecosystem of partners allows bank the opportunity to bring the newest products and services to market faster. A core vendor that limits vendor relationships may mean that a bank will wait a while longer to gain access to the newest features and technology.
- Tightness of integration. Software produced by the same company will generally integrate more cleanly than trying to connect systems from multiple firms. Tighter integration means it can feel more like one single system rather than a collection of components.
- Flexibility for third-party integration. It is important for a bank to understand its core’s integration philosophy. Does the core make integration with other firms a priority? Is it willing to partner with other technology providers? And is the technology designed with integration in mind, or does the ability to connect solutions from other companies require a secondary add-on that may delay response times and increase costs?
- Vendor management overhead. As a bank partners with more unique individual vendors, it will need additional resources to research, implement and manage those relationships. This time and attention required to manage a multitude of partnerships should not be overlooked.
- In-house technology skills. Robust technical skills may be needed on the bank’s staff if they choose to pursue and integrate multiple third parties and the latest technologies. A strong IT team and redundancy is imperative so that intellectual property does not reside in just one person. Alternatively, banks can choose to rely on a single vendor to provide and manage this technology and limit their spend on tech staff.
Listed below are five example core strategies. Each of these strategies are a basic outline illustrating the optional approaches including the high-level opportunities and challenges that are inherent with each.
Strategy 1: Single vendor, one-stop shop
This model utilizes a close partnership with a single vendor. Almost every technology service a bank needs can be met by this single provider. The vendor offers a curated suite of products through a mix of internal development, acquisition and close partnerships with other firms. In this model, technical integration and support services are provided by the vendor. This model is most often available from a provider that has the scale to offer a full suite of products to meet almost every need for each bank.
Benefits. Products will generally work well together with integration built between the products by the same vendor. Banks are not required to maintain a high degree of technical knowledge or large technology staff to support integrations. Having just one or a few vendors involved reduces vendor risk management burdens and potential conflicts between vendors. These vendors will often offer such a broad suite of products as to meet most of the needs of most banks, limiting effort by banks to research and select additional partnerships. Banks can build on a strong, trusting relationship with a single vendor to shape future technology and service delivery plans.
Challenges. Banks will be highly dependent on a single vendor for product availability and delivery. In some cases, the vendor may offer limited integration to third parties, as their primary focus may be on the buildout of their own product sets. Individual products may not be the best-in-market. Product delivery can be slower to market as the vendor builds out full integration to its suite or focuses R&D investments in other products. Partnering with a vendor with a very large customer base can inherently reduce each individual bank’s voice on development and future changes. A bank’s contract negotiation leverage with a single vendor can be harmed if agreements for multiple services are not structured coterminously.
Strategy 2: Best of breed
This model generally includes the use of an established core software solution with a blended mix of products from multiple service providers. Banks evaluate the market-place offerings to select the best solutions to meet each product need. This approach varies from the headless core strategy (defined below) in that banks typically operate from the foundation of a core database and partnership, but integrate with third parties for ancillary and specialized, often customer-facing, products. Access to an open core is critical to execute this strategy. A core hosted in and native to the cloud can support this strategy but is not required.
Benefits. Banks can select the optimal product features offered in the market for their customers, such as the best mobile apps, online account opening and back-room processing solutions, which will allow for differentiation and competition. Time to market for new products and features can be increased through the use of fast-moving fintech firms and other third party partnerships. The foundational core partnership provides basic banking services such as account maintenance, item processing and statement generation. Banks can achieve more contract negotiation leverage when they are willing to partner with multiple third parties.
Challenges. Banks must maintain a moderate or higher level of technical staffing to support a broad range of vendors and products. Integration between third-party software products may be limited by some legacy core solutions. To effectively employ this strategy, banks must constantly research and evaluate vendor solutions in the market. There is increased vendor risk due to the nature of incorporating many providers into the bank’s portfolio.
Strategy 3: Headless core
This strategy incorporates the use of a core system as a central database only. Complementary and ancillary product sets are generally purchased from third parties. A fully open and cloud-native core solution is critical to implement this approach.
Benefits. This strategy can provide maximum flexibility in the use of third parties and self-development. A purpose-built headless core can offer industry leading core database functionality that may not yet be available from legacy, full-suite solutions, such as native cloud support, extensible schemas, true real-time processing and zero downtime operations. This model offers the strongest contract negotiation leverage, as banks are able to work with the widest range of partners.
Challenges. A headless core strategy requires extensive technical skills on staff to implement and manage integrations. Ancillary solutions, including even basic services such as customer inquiry and maintenance may need to be completed using third-party software. The bank is responsible for researching, selecting and managing all partnerships with multiple third-party software providers. This approach will require strong skill and attention to thoroughly understand and manage the potential compliance challenges.
Strategy 4: Parallel “sidecar” core
The primary use of this model is to stand up an alternate bank brand or sub-brand online, primarily for deposit gathering. Banks employing this strategy maintain their primary core banking relationship and ancillary products for traditional banking customers. Additional sub-brands may be enabled online for targeted customer segments. These sub-brands typically offer limited product sets but benefit from reduced pricing per account. Additional banking services such as check processing, IRAs and commercial lending are often not offered on the secondary core.
Benefits. Fresh and innovative digital-only offerings can be stood up in short order potentially for a specific market segment. These solutions can be established in just three to four months with limited technical effort by bank staff. The cost per customer for each new account can be reduced as they do not require the support of sometimes costly legacy services. Banks are not required to complete a costly and cumbersome core system conversion to offer new products and services on a new core solution.
Challenges. Inherent with operating a second core are the increased upfront and ongoing costs of maintaining multiple core solutions. Additional operational challenges can exist for bank staff in this model with the use of multiple account databases. The benefits of newer solutions and feature sets offered by the digital-only core are not extended to the bank’s legacy customers. Some banks may run into contractual conflicts if they have previously committed to exclusivity with a legacy core vendor.
Strategy 5: Boutique service provider/integrator model
The bank’s core vendor relationship is with a services company that may use another vendor’s software and deliver to its banks much like a cooperative, leveraging the group for market advantages. The vendor may host the software in its own data center and serve as the primary point of contact for the bank. This model in many cases is similar to Strategy 1 in that the product offerings are often tightly integrated from a single suite or limited set of vendors.
Benefits. Products will generally work well together with integration built between the products by the same vendor. Banks are not required to maintain a high degree of technical knowledge or large technology staff to support integrations. Single or few vendors involved reduces vendor management and potential conflicts between vendors. These vendors will often offer such a broad suite of products as to meet most needs of most banks, limiting effort needed by banks to research and select additional partnerships. Banks can use a strong, trusting relationship with a single vendor to shape future technology and service delivery plans. If the service provider supports many banks on a single software solution, the provider may have more influence with the software developer than an individual client and be more receptive to client differentiation and innovation.
Challenges. The solution provider is not the owner or author of the software, and thus the bank may have limited input into the customization and future of the feature sets, unless the vendor owns the code. Banks may be highly limited in their product availability and delivery with a single vendor. In some cases, the vendor may offer limited integration to third parties, as their primary focus may be on the buildout of their own product sets. Product delivery may be slower to market as the software developer builds out full integration to its suite or focuses research and development investments in other products.
* * *
As you have read above, you will undoubtedly identify with one or more of the strategies, the benefits and challenges. Each of the partnership forms have their unique benefits. One of the two most important lessons from our work as a committee are that there are more providers in this space than many bankers realize, so each bank performing a search should look beyond those that they know well and educate themselves on the full spectrum of core platform providers—even if just to refine and understand options. The second lesson is that the core relationship has become incredibly complex. The technology architecture for banking is undergoing wholesale changes. Most importantly, access to data, the ability to develop APIs and flexibility in contracts will be key elements in every core selection hereafter.
The selection of a core processing vendor should not be a foregone conclusion. Before narrowing down a set of familiar vendors, each bank must evaluate its own business strategy and determine the approach that best supports the bank, its customers and shareholders for the long run.
D.J. Seeterlin is chief information officer at Chesapeake Bank, based in Kilmarnock, Virginia, and a member of ABA’s Core Platforms Committee.