By Ian Macallister, Head of Customer Success
Last month we heard top things to consider when financial institutions are implementing a new P2P payments platform. This month Chris Rigoni from Levvel discussed other important things to consider such as fees, account limits, testing, servicing and more. In case you missed it, here is our first blog on what it takes to implement Zelle.
Levvel is a technology consulting firm that works with financial institutions to design, develop and launch new payment products and services. They offer a full range of IT consulting services including strategic evaluations, requirements definition, architectural design, vendor evaluations, and custom application development and integration services.
Ian: Thanks for all the great insights last month. Let’s jump right in, should banks see Zelle as a money maker?
Chris: Zelle is a cost saver. Most banks are looking at the financial benefit from fewer checks to handle and less cash in the system. We recommend calculating ROI by observing declining check rates over a specific set of users against a control group of similar non-Zelle users and then multiplying by your true cost of processing paper. There is also a less tangible (but critical) benefit of having your customers engage with your brand to move money instead of going elsewhere. Then there is the added benefit of providing a service customers want in a fast, safe and easy way.
As for charging customers, banks determine independently whether to charge fees and their pricing structures both for P2P and B2C. We talk more about these topics in our webinar found here.
Ian: What should banks consider when deciding on daily/monthly limits?
Chris: Limits are sure to keep product managers up at night. Fraud partners will always want to protect customers and shareholders by setting a limitation on exposure, and customers will likely view limits (no matter how high) as an intention to restrict access to their money. While banks know the reasons why limits are critical, customers will probably view them negatively. For example, despite one large bank setting daily limit of $10,000 per day for certain affluent clients, they still field calls from angry affluent customers demanding that the limits be removed.
Based on what we see in the market, our advice on limits would be:
1) Keep them as high as fraud solutions permit. If fraud basis points are under control, then raise the daily/monthly limits high enough that they are less frequently an issue.
2) Keep them simple. Customer service reps will have to be able to explain the limits to angry customers who won't respond well to overly complicated structures.
3) Keep them flexible. Businesses will experience changes, both in terms of customer appetite to use Zelle, new use cases, or new fraud threats. These can happen very quickly, and banks will need to be able to respond faster than their next regularly scheduled tech release.
Ian: What are some of the most common customer service questions banks hear about Zelle?
Chris: After the initial launch, most customers ask questions about how the service works. Depending on how you’ve embedded educational material into your marketing, you’ll probably get questions about how to enroll, how to add new recipients, and even how to tell their friends from other banks how to enroll and receive funds. As your user base and transaction volumes grow, more of their questions will center on servicing issues like how to change email addresses or even how to be sure they’re sending money to the right recipient.
Ian: When building customer experience journeys, what do banks typically find most complex?
Chris: The journeys that rely on consumers interacting with the debit network and Zelle app are the most complex, if only because they require additional orchestration by the bank, including crossing two payment rails. This requires additional work both in the technology build as well as processes and procedures in the transaction settlement.
Also, banks will want to allow time to make sure they have full connectivity and access to test networks external to your institution, such as Early Warning’s test environment. These environments do offer toolsets that a team can learn to use, but education and training may take time as well as connectivity expertise.
Ian: What are some commonly missed test cases that banks should consider?
Chris: Registration of tokens for both DDAs and debit cards is an area that should receive a great deal of attention, as this is the first impression your customers will have of your Zelle implementation.
We find that testing shows us many of the issues that pop up later once a bank is in production. We recommend incorporating a broad stroke of end-to-end tests, all the way from user submission to balancing and settlement. This will include both on-us transactions as well as transactions from a variety of network banks and debit cards.
About the Author:
Ian Macallister is vice president and Head of Sales and Customer Success for Early Warning, with responsibility over Early Warning’s sales organization. He brings substantial industry and leadership expertise to the role with a focus on how to always keep the customer at the center of product and service solutions.
Chris Rigoni is a Payments Consultant who works across a variety of companies and industries to create strategic payments advantages. Chris has over 6 years of experience in managing emerging payments and digital platforms and has served as a subject matter expert in tokenization and digital product management. The last 3 years have focused on tokenization, Zelle, and real-time payments strategies within organizations of different sizes and needs.
Levvel helps clients transform their business with strategic consulting and technical execution services. We work with your IT organization, product groups, and innovation teams to design and deliver on your technical priorities. The Levvel Payments practice combines real-world experience and insider knowledge to help you navigate the complex arena of payments. For more information, contact Levvel at firstname.lastname@example.org.