January 20, 2020
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. To help your bank build a knowledge base and prepare yourself to ask the right questions (both internally and externally), Levvel has composed a list of key questions and considerations that you (even small businesses) can use to prepare.
These questions are based on Levvel’s extensive experience with Zelle, including both business considerations (e.g., business requirements, operations, fraud prevention) and technical considerations (e.g., architecture, design, coding, and implementation). Of course, there are always unforeseen considerations. The key is to always ask a lot of questions, both of your internal teams and any external providers. And don’t forget EWS (Early Warning Systems) is always available as your partner and guide.
Integration strategy is the first step in the process and one of the most important, as it will be the driving force behind the entire integration. There are two main integration strategies banks can consider when integrating with Zelle, first by using a reseller (like Fiserv or FIS) or to directly connect via custom-built software. Both have pros and cons that should be carefully considered when deciding the one that is best suited for your institution.
Most financial institutions start by going to their current vendors to gain an understanding of what solutions they offer. Most of the major vendors offer a “turn-key” Zelle solution. While these solutions provide fast access to the network, there are areas that should be considered to ensure the appropriately address all your Zelle needs.
Integrating Zelle into your institution’s portfolio impacts virtually every major internal system (e.g., deposits core, reconciliation, fraud). It’s important to understand how the Zelle transactions will flow from the reseller’s solution to these crucial systems.
The majority of the reseller Zelle offerings are built on existing solutions used by other payment platforms (e.g., ACH, Wire). This approach can provide a quick and familiar path to get Zelle up and running. However, it can also lead to gaps in the user experience for specific Zelle use cases. It is important to review and the overall flow of the solution to ensure a complete and enjoyable end-user experience.
The largest consideration of any project is the cost. Understanding the upfront and recurring costs associated with your 3rd party reseller is crucial. Many resellers have minimum annual costs that must be met in order to leverage their features. Those ongoing fees, coupled with any upfront setup, testing, or configuration costs, need to be considered when looking at the total cost of ownership and operational maintenance.
A Zelle integration is only as good as the integration with your banking core. Many pre-packaged Zelle offerings are built on top of existing functionality. This means the integrations and interactions with your internal banking systems, including your core, may have been built to satisfy one type of payment network and “tweaked” to try and support Zelle. This type of augmentation can be a quick integration or can leave a gap if this is the first product you are integrating with that vendor.
What you want and need out of a reseller offering will almost certainly change over time. The initial configuration usually gets reduced in favor of a faster time to market and/or lower costs. Understanding how quickly and easily customizations can be made throughout the life of the contract is an important question to pose to any potential reseller.
The Zelle Network, like any other well-established solution, must stay current with an ever-changing world and customer base. These changes can occasionally require significant changes to your internal integrations, which will need to be completed and tested in plenty of time to ensure continued compliance with the Zelle network. You should make sure to understand how your vendor handles these update cycles to ensure your internal release schedule is aligned.
Many banks want to get their Zelle offering to market quickly while working to bring it in-house over the long term. To do this effectively, you should be looking at what integrations your reseller can easily support now, as those will likely be the integrations you will be responsible for developing when making the move. Having a good understanding of what all will be impacted if you remove the reseller can be key in determining if/when you decide to develop the Zelle integration yourself.
The number of banks that a reseller currently has live with Zelle, and other platforms, can provide several indications of how smooth your Zelle deployment and long term maintenance will be. Resellers with a smaller number of clients live on their platform tend to be a bit more flexible as it relates to customizations and have more ability to provide focused attention to your implementation. However, this can also leave you with a smaller group of peers to collaborate with during testing and when trying to push for changes. Conversely, resellers with a larger number of product clients offer a larger support group and potentially a more stable and well-vetted solution. However, the more clients that need to be serviced can significantly reduce the amount of individualized support and can lead to your issues being queued up to be handled by the next available representative.
The introduction of a new service or product brings with it new questions and issues that your operation and call center teams will need to handle. These teams will be the main line of support for your clients, and their ability to quickly identify and resolve the issue will ultimately determine success or failure in the eyes of your clients. Understanding what data and how to access it quickly should be a major consideration when selecting a reseller for Zelle.
For those wanting to tailor and customize the full Zelle integration to their unique institution, direct connect offers that ability. This strategy allows a bank to build the integration precisely to their specifications. However, it also requires that the bank is fully responsible for not only building the solution but also maintaining and supporting it. This amount of work can sometimes be too much for a bank to take on. Therefore, you need to review some key aspects of your institution when considering direct connection.
Having the right people and skill set is imperative to developing your custom integration. The team must be knowledgeable of not only Zelle and the banking/payments industry, but they must also be skilled in the latest technologies, development best practices, and integration techniques. These teams can be in-house or provided by a third-party technology firm. Either way, an institution must be comfortable with the ability of the team to deliver.
During development, engineers will need a way to confirm their code integrates properly with internal bank systems, as well as Zelle itself. Procuring and configuring lower-level test environments to mimic the production environment will help identify issues very early on and reduce the cycles the engineers will have to spend to redeploying and testing fixes. For FIs with wholly-owned internal systems, this task is generally straightforward, but for smaller organizations managing multiple vendor integrations, more coordinated effort will be needed. Coming up with a way to accurately test your integration in these lower environments can be challenging, but doing so can greatly reduce the number of support issues and improve the overall customer experience.
Depending on which methodology you choose for your development (e.g., Agile, Waterfall), making sure that you are aligned with how your internal system teams work can make or break an integration’s timeline. Much of the P2P integration will be dependent on other systems and teams being ready to integrate with your systems. If these teams are not ready or have prioritized other initiatives over your integration, then you will quickly hit roadblocks and delays waiting on them. Ensuring a clear and concise roadmap, timelines, and cadences amongst all involved teams is a great way to keep your Zelle integration on schedule and budget. This especially applies to the early technical designs—it is critical to maximize the discovery of dependencies and implications before development starts. Finding an experienced Zelle partner to help coordinate, align, and drive this can help ensure a successful Zelle launch.
Getting the integration built, tested, and deployed is just the beginning. You will need a team of people available to monitor and maintain the system out in production. This maintenance includes internal issues, such as identifying and correcting bugs in the integration code, as well as external factors such as system integration interruptions, outages, hardware updates, and scheduled maintenance. Having these teams identified and on the ready will help ensure success after your integration is in the hands of your customers.
Integrating the Zelle P2P service will impact virtually every area of your bank’s ecosystem, from the front-end user experience to the back-office operations teams and everything in between. A successful integration story begins with understanding which teams will be impacted and getting everyone to the table early to ensure everyone is on board and to continue to communicate and collaborate throughout the integration.
Your core system is at the heart of everything that happens at the bank. Understanding how Zelle payments will be processed through the core should be near the top, if not the top item, on your Zelle “to do” list. You will also want to understand which ancillary data streams integrate with your core and where those capabilities reside. If you find a large number of non-core data integrations bolted on to the core, you will want to capture and plan for those additional dependencies.
While Zelle is not a true real-time payment rail, its rules for participation and good-faith transaction model require that it looks and acts like one to your end-users. This means that your core needs to be able to accept and post the funds immediately so your customers can have immediate access to their funds. The majority of bank cores are batch-based, so understanding how to get the core and related systems to support real-time fund posting is critical.
Real-Time funds transferred via Zelle must be available to your customers 24/7/365, which means your customers must still have access to their funds even while the core is offline processing batches. Understanding how this occurs and identifying possible issues must occur early on in the integration planning and design.
Communication to the core is paramount. An Application Programming Interface (API) is the most commonly used way for systems to communicate with each other. Working with your internal system teams to identify the various APIs that are available and what is required to leverage each one can help reduce the friction of your integration.
As with any transaction, being able to trace it through your ecosystem will be imperative. Every Zelle payment is tagged with a unique payment ID. If your core can support storage & access of this ID, then leveraging that may be the best course of action. However, if the ID of the core does not fully align with the Zelle rules, you will need to find an alternate way of linking the Zelle transaction to the transaction sent through your core. This can be accomplished by leveraging a different storage slot in the core transaction or possibly by creating a new storage/retrieval mechanism to associate the records together.
Unless you have a true real-time core, it’s distinctly possible that you will end up in a situation where a Zelle payment results in a non-sufficient funds (NSF) scenario for your customers. Being able to accurately check the available funds of a customer’s account before initiating a Zelle payment is the best way to prevent this from happening. However, even the best-laid plans can fail, so understanding how to handle this type of scenario both internally and with the end-user will help reduce friction and headaches.
Additional consideration should be given to care for internal system outages. Whether the outage is related to regularly scheduled system maintenance, or an unplanned outage, you will want to consider stand-in processes that can support Business As Usual (BAU) processing until full system functionality is restored.
Zelle is not a new payment rail. It is a Shared Directory that leverages existing payment rails (e.g., ACH, Debit) to create a good-faith funding model to provide recipients with instant access to the funds. Funds sent from one DDA account to another will still settle over the existing ACH or card rails; therefore, your ACH payment processing flow will need to be updated to handle these Zelle transactions.
In most cases, when you are sending money to another enrolled participant, the funds transfer will occur in minutes. Also, for interbank transfers (when both sender and recipient are within the same FI), the institution may initiate a debit entry to your account to facilitate the transaction.
The majority of Zelle transactions will be settled via standard ACH batch file processing, which means your ACH system must be able to identify and pass these transactions to your P2P system for processing. This means that the ACH system must be able to trap these Zelle transactions and send them through the P2P system to complete processing. Each Zelle payment is identified with its Zelle Payment Id in the addenda record of the NACHA entry. Determining the best way for your ACH system to trap these transactions to P2P for processing will ensure that Zelle transactions do not cause reconciliation problems.
If a non-expedited Zelle payment is sent back via an ACH return file, you will need to ensure an effective way to update that payment in the Zelle network. This can be accomplished systematically by passing a list of returned payments through your P2P service or manually via an operations dashboard. These scenarios are not common, but being prepared for handling special cases like these will help ensure that any unforeseen circumstances can be easily addressed.
Fraud mitigation is an integral aspect of any successful Zelle offering. While EWS has an in-house team dedicated to fraud risk management, it is critical that Zelle network member banks take the necessary time to assess enhanced controls to support the real-time nature of payments within the Zelle network and ensure you and your customers are properly protected.
A good plan for how to protect your bank and customers against fraudulent payments is at the forefront of most banks integrating with Zelle. While real-time fraud decision making is not a requirement to use the Zelle service, being able to identify fraudulent payments in real-time can go a long way in mitigating fraud at its source. This can save countless hours and dollars that would be otherwise spent by your loss prevention department to attempt to reconcile fraudulent transactions.
As with every payment integration, fraud is a fact of life, and Zelle is no different. Identifying your bank’s risk tolerance will be a key item in helping to identify what fraud prevention measures you need to implement and how restrictive those measures should be. If your fraud checks are too open, the amount of fraudulent payments can quickly spiral out of control. Conversely, too restrictive can have a significant impact on the overall user experience. In either case, your Zelle integration can be seen as a failure and cause your institution to see significant losses, both financially and in reputation.
When implementing fraud prevention, it’s important to take a look at what tools are currently employed by your bank. Most of these tools, with a few focused configuration changes, can be reused to help address fraudulent Zelle payments. Tools such as one time passcodes (OTP), biometrics, and mobile device identification are a few examples of tools that can help your customers from falling victim to fraudsters. One of the most important tools is education. Educating your customers on what to look out for, informing them that you’ll never ask for them to provide the OTP over the phone, and other means of helping your customers become more informed about fraud is a key component of any successful Zelle integration.
A Zelle transaction will most likely be set up as a new product or transaction type in your bank’s ecosystem. This distinction is a key factor in helping to adjust and dial in your fraud tools. While Zelle leverages existing payment rails, you likely won’t want to employ the same rules and scoring as you would a standard ACH payment. The way that a Zelle payment is initiated and the party/counterparty data introduces some unique challenges that should be accounted for by your fraud tools. Being able to identify these payments to your fraud systems easily will be vital to ensuring the right rules are applied.
Once you get all your fraud tools identified and dialed in, you will now need to have a plan for how to address those payments that are denied due to your fraud rules. How your system handles these, both from an end-user and an internal perspective, is an important aspect to consider. Payments can be denied for more than just fraud. For example, the account could have insufficient funds, or there could be temporary holds on the accounts. Taking the time upfront to identify these scenarios and how each one will be handled by both the system itself and by the customer support teams will help mitigate the negative experiences of your customers when they occur.
Fraudsters have become adept at using phishing or malware attacks to gather compromising user information to attempt account takeovers. Methods such as stronger authentication requirements, device binding, and malware detection can aid in preventing these types of attacks from being successful.
Adjustments to your fraud systems will occur periodically throughout the life of your Zelle integration. Understanding the time it takes to make these adjustments can help in planning these changes in the production environment. If fraud rules can quickly and easily be changed, this will reduce the impact on your customers or business. Zelle transaction and frequency limits can also serve as a fraud mitigation tactic, provided you maintain operational oversight of when and how they are administered. However, if the time to complete updates is lengthy, then you need to be a bit more precise or tolerant of fraud risks because it will just take longer to refine the rules.
Denials can happen at any time during Zelle payment flow. Clearly defining process and procedures for handling these denials is important. One of the more frustrating denials will occur when your customer attempts to enroll their mobile number or email in your service. Properly capturing the reason for a denial and leveraging that data to help your customers understand what is going on will be important to reduce the amount of friction and anger experienced by your customers.
While having a real-time fraud decision engine is highly encouraged, banks should give their operations’ staff a measure of control in overriding the automated process in favor of manual validation. Exception transactions should move into a queue where operators can decision individual transactions starting with the riskiest, working down to the least risky. After a predetermined period of time, a decision should be made whether to preemptively release payments into the Zelle network, or not.
The most visible part of any Zelle integration is the front-end user experience. Early Warning Systems (EWS) has created a very distinct style and user experience guide that outlines the pages, prompts, and flows required for integrating with Zelle. While the branding and experience of Zelle should “feel” the same across all institutions, how that experience integrates into your existing UI is still a unique challenge you will need to address. You will need to work closely with whoever maintains your existing online and mobile UIs to ensure that the integration of Zelle fits and does not present an unfamiliar or “clunky” experience for your users.
Zelle has some rules around what data elements must be present on various customer statements, such as the sender/recipient name, date of transaction, and amount. Each statement presented to the customer can have a variable number of characters that are supported on each line of text. Having your marketing teams review each scenario and determining the correct text to include can help reduce the time spent during the implementation and allow teams to focus on the more technically challenging aspects of the integration.
Communication with your clients regarding Zelle transactions is crucial. An enterprise messaging hub can help centralize and standardize how these notifications are constructed and sent out. The hub can also support the storage of customer communication preferences (e.g., opt-out) and apply those preferences to each notification that needs to be delivered.
Integration with Zelle requires several notifications to be sent to the end customer at a specific point in the various use case flows. Many of these notifications are required to be sent. However, there are a series of notifications that the end-user can opt-out of receiving. The Zelle system must provide all the necessary information to tell the notification system which notification and the customer to which that notification should be sent. The notification system is responsible for locating the target customer to ensure that they should receive the notification.
Using this Zelle integration checklist to accurately assess your current architectural environment, identify the challenges your institution will need to address, and plan appropriately to deliver a high-quality experience for your customers. Whether you are in the process of implementing Zelle or planning your integration, this checklist will help guide your decisions and ensure you are on the right track.
As payment systems domestically and internationally adopt faster money movement, your customers are doing the same. To remain competitive, providing your customers with accessible, competitively-priced real-time payments will secure your position both in the market and as their financial institution.
Our team is made up of leaders, thinkers, designers, and builders whose collective experience spans many industries and companies of all sizes. We’re avid fans of technology but even bigger fans of solving business problems. An understanding of the difference between an idea and a solution is just one of the things that set us apart.
Our Financial Services & Payments Practice combines enterprise payments experience, technical expertise, and a pulse on emerging technologies to ensure our clients create the right approach the first time. Our team has broad, strong industry relationships and expertise across the payments ecosystem.
Client Solutions Lead
Financial Services Consultant
Jonathan Parker is a Client Solution Lead in the Financial Services Practice at Levvel, responsible for ensuring quality delivery of all aspects of a project within the financial services and payments market. Parker has over 15 years of consulting experience, primarily focused on application development, architecture, systems integration, and technology leadership. Parker builds and maintains strong business and technology partnerships to ensure smooth, consistent progress through all phases of a project. He recently led a team who handled the end-to-end development and successful Zelle integration for a US top-50 regional bank.
Chris is a Financial Services Consultant who works with financial institutions and enterprises of varying sizes to help them identify and implement their payment strategies. He comes to Levvel with 9+ years of experience in banking having held various roles in Treasury Management Sales and Product Management, as well as Direct-to-Consumer Digital Transformation.
Now that 2020 has arrived, the reality of RTP adoption has begun to outpace planning for implementation. The RTP conversation is no longer around should it be implemented, but rather of use cases that have been missed to better serve customers.
Throughout this series we'll provide answers to frequently asked questions surrounding product management for RTP, such as managing the product(s) long term, dealing with cannibalizing current products, and more.
TCH’s RTP adoption is rising. A recent study noted 74 percent of small and large institutions are considering RTP or have begun implementation. Although a large majority are adopting RTP, there are many differences for RTP within small or large FIs.
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.