August 15, 2017
TABLE OF CONTENTS
Over the last month, the Levvel team has been writing about our experience helping banks onboard to the Zelle network. We have walked through what Zelle is and why it matters, dug deeper into how different banks are looking at Zelle as table stakes or a strategic differentiator, and now we’d like to discuss what we’ve found to be the three general approaches for banks to integrate with Zelle.
For most people, the roll-out of the Zelle brand is the first time they have heard of the functionality that has been quietly facilitating the peer-to-peer (P2P) payments offering at many major US banks for years. Previously operated as clearXchange, Zelle was built by Wells Fargo, Bank of America, JP Morgan Chase, and later expanded to include Capital One and US Bank, among others. For these banks that participated in the clearXchange launch or joined shortly thereafter, there was minimal additional work required to launch with Zelle. Most of these banks choose to continue with their direct integration approach. We feel that the most complex and ultimately strategic approach is for a bank to work directly with EWS to integrate into the Zelle directory and network, much like the large banks have already done.
Despite this, the decision to do so is more complex for middle-market banks. For many of these banks, technology dollars are tight, and the perceived lack of business case for P2P payments creates the need for additional scrutiny over the scope of a Zelle project. In our last article, we discussed several ways to build a business case around Zelle and how to position it as a strategic differentiator. This included future use cases like disbursements, bill pay, and broader money movement strategies. For a bank to be best positioned to take advantage of the newest features and uses cases made available by Zelle, they will need to work directly with the platform and often need a direct integration.
This may not be completely obvious, given that the sales materials from leading resellers promise the integration of all desired future functionality. However, we often find that some of what is promised has yet to be built. In contrast, banks that integrate directly with Zelle will have access to the features as they become available and can then begin building business models, products, and workflows utilizing the new features as soon as the specifications are released. We find this particularly useful for banks that have uses cases stretching across both the retail consumer and the commercial sides of the bank (since most vendor products do not stretch to both sides).
There are some downsides to this approach, including a higher initial cost of integration, time to market, the need for skilled internal labor, and potentially needing to hire an implementation partner. Ultimately, the direct approach seems best suited for banks looking to leverage the Zelle directory and network to build a market-differentiated approach to payments across different payment rails. Additionally, banks looking to reduce their platform vendor footprint in core business functions by bringing key functionality in-house will often find direct integration to be an optimal path.
The above scenario works well for mid-sized to large banks with sufficient IT budget and business focus on the future of money movement capabilities. But what about the small regional banks and credit unions? We have found that many of those financial institutions take an approach on the opposite end of the integration spectrum by leveraging a “reseller,” such as Co-op, Fiserv, FIS, or Jack Henry. For the smaller banks, these partners often already operate the majority of the bank systems that serve as integration points for Zelle, including the mobile/online experience, core deposit system, ACH system, and bank messaging platform. Not only do these banks tend to lack the internal development resources needed to perform a Zelle integration, they also rely on vendors so heavily that building and operating a custom piece of software is often not an option.
One additional segment of banks we see leveraging resellers consists of those that were previously using Fiserv’s Popmoney, TransferNOW, or BillPay products for other money movement activities. For these banks, Fiserv presents an option that encapsulates most of the required Zelle integration points into already implemented interfaces the bank has with Fiserv. We have also seen this path become appealing to larger banks that have prioritized other efforts such as mobile wallets or API gateways and wish to be part of the Zelle movement, but with minimal cost.
While leveraging a provider is a perfectly acceptable solution for a wide range of banks, we advise that banks step into these partnerships with a clear understanding of what they will get from the vendor on day one and what is a future-state or road map feature. In some cases, the first bank to hire the vendor for this functionality will be the one working to build it, and only then will it become available to all other banks on the platform. This inherently means the bank will not be able to offer a differentiated product. This is nothing new, and most banks have come to accept that the large vendors provide features only after they are battle tested with other customers, but it does mean that it will be hard to differentiate amongst your competitors.
Additionally, leveraging “turnkey” solutions also means that a bank’s ability to leverage that integration across multiple lines of business or products is severely limited. This is often the result of tightly coupled experiences and services that can’t be customized or altered to facilitate incorporation of other vendors or homegrown products. Lastly, this type of integration can be somewhat challenging for banks leveraging multiple vendors for key components of the Zelle integration. As an example, a bank using a Hogan core with a FIS online banking interface and a Fiserv Pep+ ACH system is going to have a number of complex integration challenges hooking all of these products together and will likely need outside guidance.
So far, we have discussed the two opposite ends of a Zelle integration approach:building the integration in-house or utilizing a turnkey partner. For some banks, a direct-to-Zelle approach is too large of an effort while using a turnkey partner limits them in their desire for flexibility and how the product is implemented. For these banks, it is often best to approach Zelle with a hybrid model, choosing to leverage a vendor such as Icon, Co-Op, or FIS for key pieces of functionality while building other core components themselves. This approach is often ideal when the bank is also targeting the implementation of a new vendor product such as a payments hub, ACH system, or Bill Pay platform. In these cases, selecting a vendor that already has Zelle interfaces available as part of the core product offering means the bank is able to accomplish two objectives with one purchasing decision.
Additionally, this approach often means the bank is leveraging the APIs from their vendors and allows for a more loosely coupled integration of user experience and back-end functionality. As a result, the bank has more flexibility as new features become available to alter the experience or incorporate a new money movement rail or feature.
An additional area where this approach has become prevalent revolves around banks that are looking forward to the TCH Real Time Payments (RTP) network and are planning accordingly. For many of these banks, an API gateway such as Red Hat’s 3scale or Google’s Apigee platform, a payment hub such as D+H’s, or a payment framework such as Icon’s IPF provide a nice toolset for building future payment products, including Zelle and TCH RTP, while also allowing for bank-specific workflow customization and control. Most of these partners provide some Zelle interfaces out of the box, but they also integrate into customized bank logic and flows, ultimately providing the best of both worlds.
The approach that works for any given bank depends on a number of factors, including budgets, internal IT capabilities, and current vendor relationships. While many larger banks will continue down their traditional path of either building internally or outsourcing, the real opportunity lies with the mid-market banks who have a chance to start punching above their weight by building the right features that create value and resonate with their customers.
Over the next several years, the combination of Zelle and TCH RTP will allow banks of all sizes to create new business cases and market opportunities if they form the right partnerships and build the right technology. Levvel is actively working with a number of US banks to help inform these decisions and ultimately design and build the integrations needed to ensure success with these products.
Interested in learning more? Contact us at email@example.com.
Chief Strategy Officer
Scott Harkey is Levvel's Chief Strategy Officer while also leading the Payments and Financial Services work. He has 15 years of banking experience including leading the technology team that implemented digital wallet products at Bank of America along with 10 years of technology merger integration and IT operations outsourcing work at Wells Fargo. Scott brings a unique “insider” point of view combined with a proven track record of delivery to banks, technology providers, and merchants exploring the digital payments space.
In 2019, we participated in the RTP Buildathon, sponsored by The Clearing House, Oracle, Yodlee, and The Carolina Fintech Hub. Our task was creating a compelling use case for leveraging the RTP rail and building a working prototype to demo our idea.
Integrating the Zelle P2P Service into a financial institution's ecosystem is an incredible opportunity, but the journey to get there can be a rocky one for institutions not adequately prepared.
Real-Time Payment (RTP) adoption and readiness have been a point of consideration for Financial Institutions (FIs) dating back to The Clearing House’s (TCH) announcement to launch the service back in 2014.
Sharing insights from the Go developer conference in San Diego, affectionately referred to as GopherCon, to try and answer a fundamental question: should Go be used for enterprise applications?