May 24, 2018
Banks of all sizes continue to face threats from third parties interested in taking over key parts of the traditional bank customer experience. Many banks believe that conceding the customer experience to parties like Venmo, Google, and Square Cash will ultimately amplify the effects of disintermediation, further diluting the value proposition of banks in the eyes of customers and reinforcing their use of non-traditional services.
As a result, products like person-to-person payments are now table stakes for banks who want to ensure that customer interactions with their money occur through a channel and experience that they own. Given the nature of P2P, banks must work together to create ubiquity, so that any customer of any bank can send money to any customer of any other bank, and so that the experience is on par, if not better, then what these competitors can provide.
Zelle is the platform for creating that ubiquity; however, integrating it into a bank is no trivial task. Banks considering a Zelle integration should use this document as a high-level guide for identifying critical areas of focus and potential challenges upfront.
In today’s rapidly evolving payments landscape, traditional financial service providers are on the defensive, experiencing regular attacks on multiple fronts. A key area where banks are being challenged is the P2P money transfer space. The number of P2P providers has increased dramatically, and more and more traditional bank customers are looking to third-party solutions to meet their needs.
Venmo, a popular P2P service owned by PayPal, experienced 174% year-over-year growth in 2015. Square Cash processed $1 billion in transactions— within two years of launching. Given the obvious customer demand for P2P services, and the well-established trust that banks already enjoy from their consumers, P2P payments represent a key, strategic opportunity for banks to better service their customers.
P2P is not a new concept for most banks. Every month, millions of dollars are sent via existing P2P tools offered by major financial institutions (FIs). Many customers at large banks with transfer capabilities are familiar with the process of logging into their online banking (or mobile) site and sending money to a friend who is at the same bank. But what about when they bank at different places, or when the customer doesn’t want to ask their friend where they bank? The big banks have solutions for this as well, but most customers either don’t know they exist or don’t know how to use them. Furthermore, they are not universally accepted.
For many users, the allure of using third-party P2P solutions is that they know it will always work, regardless of where the sender and the receiver bank. These bank-agnostic services employ different methods to make that happen: Venmo uses a stored value account, while Square Cash makes the receiver link a debit account to receive funds.
Whatever the method, they all provide the same value: facilitating the movement of money from person to person through a simple, elegant user experience. The challenge for banks, then, is to replicate that seamless experience and broadly communicate the interoperability of their service to customers across multiple banks. The answer to this challenge is Zelle.
In 2011, Bank of America, Wells Fargo, and Chase joined together to form an entity known as clearXchange (CXC, now Zelle), with the goal of improving upon existing bank capabilities for transferring money between individuals. While the network ultimately leveraged traditional ACH files to trigger the movement of money, it added a shared directory structure and set of ows, operating rules, and agreements that allowed a customer at Bank A to transfer funds to a customer at Bank B in “real time,” provided that both the sending and receiving banks were within the Zelle network.
Since that time, Zelle has added several other banks to its ownership, including US Bank, PNC, and Capital One. Its acquisition by Early Warning Systems (EWS), introduced several other changes, including the addition of fraud detection and authentication services. Perhaps more importantly, it also brought a renewed focus on expanding the Zelle product beyond the initial core set of banks and on establishing a stronger brand awareness with customers.
The EWS merger brought a renewed focus on expanding the Zelle product beyond the initial core set of banks and on establishing a stronger brand awareness with customers.
Before we dig into some common challenges banks face when implementing a Zelle-based solution, let’s first look at how the solution works.
The core of the Zelle solution consists of a Zelle-hosted directory of users stored in the form of an email address or phone number (known as a token) and the underlying FI to which the user is linked. The Zelle directory facilitates the routing of transactions to the appropriate institution with only the user token, keeping all sensitive account and customer information within the FI that owns the customer relationship. Zelle also hosts consumer-facing online tools for users that are not part of a Zelle member bank; however, these are mostly used by customers who are registering to receive funds at a non-member bank.
In the most simplistic use case, a customer logs into his or her bank’s online or mobile site and utilizes a “Send Money” function to trigger a Zelle-enabled transaction. How this is implemented varies slightly from bank to bank, but it usually consists of the following steps: registering the sender with the Zelle directory (which may happen behind the scenes), capturing the recipient’s phone number or email address, registering that information with Zelle (if the recipient isn’t already registered), then triggering a memo post to the sender account in order to deduct the amount sent.
The bank then preps a file that includes a Zelle-specific Payment ID in the addenda record, sending it to their ACH processing system during regular processing and using it to notify Zelle of the transaction. Zelle then notifies the receiving bank of the pending transaction, which noti es the receiving user of the pending payment and the timing of its availability. The receiving FI typically uses an account number for a settlement account marked for all Zelle transactions. That FI is responsible for using the payment ID supplied in the addenda record to identify Zelle transactions and to transfer the funds to the customer’s account for posting.
This “simple” use case does not address important nuances, however. While the fundamental Zelle model is fairly straightforward, use cases can quickly become complex in exception scenarios. Examples of such scenarios include when a receiver does not bank at a Zelle member bank or is already registered through a different bank than where they want to receive the money.
Zelle does provide a framework for addressing specific use cases in the form of Operating Rules, to which all member banks must comply. These rules detail all the basic use cases a participating bank must support, including: sending and receiving funds, account and token maintenance, and customer noti cation requirements. However, the FI must still determine whether they have their own company-specific scenarios or other considerations to address. This is in addition to the integration work that will be required.
It’s common for banks to have questions about the integration required to support Zelle. When assessing the Zelle model, many FIs focus solely on the customer-facing components required. The impacts to a bank’s mobile and online channels are straightforward. Likewise, the messaging requirement is easy to understand and is well within the capabilities of most banks.
The impact to the bank’s core bank systems is less obvious, however, so it is important to understand why back-end integration is required at all. To illustrate this point, below are several common scenarios triggered by events within core bank systems that would affect the Zelle network:
Furthermore, integration with Zelle often occurs within the much broader context of bank systems. For example, most banks have some or all the systems represented in the diagram below (see Figure 1), many of which are impacted by one or more Zelle use cases.
Figure 1Most banks have some or all the systems represented here, many of which are impacted by one or more Zelle use cases.
An implication frequently overlooked by many is the need to support both batch and real-time communication with bank systems. For example, when a customer at Bank A sends money to a recipient at Bank B, a real-time notification is sent to Bank B. The receiving institution is responsible for handling that message by generating an email or SMS alert to the recipient—in real-time.
Another requirement that some issuers find challenging involves the batch processing required by ACH files. When an ACH file is received that contains Zelle transactions, those records must be batch processed with additional logic outside of the ACH platform.
Data in the addenda is used to identify the Zelle transaction and transform the transaction to credit the recipient’s account within the institution. Facilitating this process requires enhancing the bank’s ACH system, core deposit system, or possibly both.
These are just a few examples of the types of events that frequently require core banking system integrations or enhancements but are often overlooked during an initial assessment of Zelle. In addition to these enhancements, new development is also typically required.
When assessing the Zelle model, many financial institutions focus solely on the customer-facing components required. The impact to the bank’s core systems is less obvious, however, so it is important to understand why back-end integration is required at all.
As previously mentioned, integration with Zelle must be viewed within the broader context of a bank’s technical infrastructure. We have already addressed how the bank’s channel apps and core systems will be impacted, but the FI must also create new applications or services as well. These services are best understood in the context of specific Operating Procedures or Use Cases de ned by Zelle, including:
Some of these services require new work flows and orchestrations that are specific to Zelle. Many of these interactions would need to occur between existing core systems. In some cases, the interactions may require modification to an existing enterprise system, or the creation of an altogether new one. They also create patterns that banks typically have not accounted for in their system architecture.
The last use case listed above, where a customer sends money to a person that is not a member at another Zelle bank, is a perfect example. In this case, the sending bank must contact the receiver and provide instructions for registering with Zelle. This tends to present a challenge, as banks often have their notification system tied to a user profile, which is in turn often tied to an online banking ID or customer account. Since the receiver is not a bank customer, there will be no customer ID or online banking ID to which the bank can attach the user contact method. In addition to the technical challenge presented, this scenario also invokes privacy considerations, introduces new customer service scenarios, and requires legal and compliance approvals.
All these examples can be solved with technology and business process solutions, but they must first be identified and analyzed during the bank’s assessment of the Zelle effort.
Another decision banks must make as they analyze the effort to build these services is which of them to build as Zelle-specific services and which to build as shared enterprise services for use elsewhere. The rapid evolution in the payments space and the regular introduction of new partners and opportunities leads many banks to consider more holistic implementations of any new functionality. Banks should perform the due diligence up front to assess the pros and cons of a shared services model from both a business and technical perspective.
Yet another area that gets overlooked until much later in the implementation timeline is customer service. While customers primarily utilize the Zelle functionality through online and mobile banking channels, there are still customer service implications to consider. We’ve already mentioned the messaging component of customer service, but additional use cases that require functionality include:
Financial institutions that integrate with Zelle should approach the effort with an end to end view of what it takes to operationalize the product and not simply focus on the initial technical integration.
While every FI is unique, any FI seeking to integrate with Zelle can do the following to get a clearer picture of the effort required—and perhaps reduce it.
Perform a comprehensive architectural assessment of your payments systems prior to developing the Zelle-specific architecture.
Consider building a Token Management System/Database.
Thoroughly investigate the capabilities of vendors and partners with regards to the specific integration needed for Zelle.
Carefully review ALL the required Zelle Use Cases prior to scoping the effort.
These are several of the major lessons that we learned while helping banks integrate with Zelle. While there are many other items that must be addressed, taking these into consideration should help you form a better understanding of the overall effort.
Levvel helps banks simplify and accelerate the adoption process for Zelle. Our Payments Practice includes members from the original team that designed the Zelle directory and implemented the Zelle solution at one of the original member banks. We have assisted other institutions in building their business strategy around P2P payments, assessing the effort to onboard with Zelle, and designing and building for a Zelle integration.
Levvel has helped four of the top five and nine of the top fifteen financial institutions in the United States with strategy consulting, product design, technology architecture, and solution delivery. The team understands the challenges banks face: a highly regulated environment, margin compression due to legislative changes, increased threats of disintermediation by new non-bank competitors, and legacy technology environments all make launching new capabilities challenging.
We can assist with all phases of a Zelle integration including:
Additionally, Levvel’s technology partnerships with companies like Red Hat, Pivotal, and Docker means the solution Levvel delivers will work within your existing IT standards.
Founder, Chief Executive Officer
Chief Strategy Officer, Head of Financial Services & Payments
Meet our Experts
Founder, Chief Executive Officer
Chris has more than 15 years of technology leadership experience with a specialized focus on financial technology solutions in the consumer, commercial and wealth management space. He has led software development, infrastructure, and QA organizations at multiple Fortune 100 companies and also helped grow and launch a number of early-stage technology companies. Chris’s technical expertise, startup experience, and global program management background enables our ability to support a wide range of clients at all stages of transformation.
Chief Strategy Officer, Head of Financial Services & Payments
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.
You're doing big things, and big things come with big challenges. We're here to help.