2020 Real-time Payments Report

The Reality of Real-Time Payments

Real-time payments (RTP) is here, and it is not limited to big banks. Smaller and mid-sized financial institutions (FIs) understand the benefits and are considering adopting RTP. Now that the technology is available and customer demand for frictionless payments is widespread, these FIs are recognizing that to maintain customer satisfaction, reduce customer attrition, and support internal cost-saving initiatives, they will need RTP.

RTP, the new rail for clearing and settling transactions between accounts at FIs in real time, was created to better meet business and consumer expectations for a faster, smarter, more secure ubiquitous payments solution. After three years of development with the support of its owner banks, The Clearing House (TCH) launched its RTP® network in November 2017. The first RTP transaction was completed by U.S. Bank and BNY Mellon in only three seconds.

RTP serves as an alternative payment method to options such as checks and ACH (Automated Clearing House), which use batched or delayed payments. RTP allows entities to make instant business-to-business (B2B), peer-to-peer (P2P), business-to-consumer (B2C), and consumer-to-business (C2B) transfers—24/7/365.

Levvel Research undertook research at organizations ranging from community banks and credit unions to multinational companies to uncover the drivers behind RTP, the challenges FIs face in adopting RTP, their readiness to implement RTP, and their implementation strategies.

The insights shared within this report will enable FIs to:

• Understand FI expectations for faster payments
• Summarize the business and technical challenges and considerations for RTP in order to focus transformation efforts
• Develop a strategic roadmap to seize the opportunities presented by RTP and create ROI

RTP for the FI

RTP processes near-instantaneous transfers between FIs using a consolidated, pre-funded Federal Reserve (Fed) account; payments are finalized in under fifteen seconds. Transfers are executed through a credit transfer payment message within TCH’s RTP network, where Fed ledger balances for each institution change as money is transferred. Sending banks that want to originate RTP transfers must pre-fund their designated Fed accounts, typically with a balance that reflects anticipated RTP activity.

RTP consists primarily of Receive, Send, and Request for Payment (RFP). Other functionality includes value-added messaging such as supporting messages for exchanging data and other information.

When implementing and launching RTP, FIs must adopt a specific persona (see Table 1). Each persona has minimum requirements regarding the messages the FI must support. For example, an organization that decides to implement the Receive Only persona must at a minimum create infrastructure to support a credit transfer, remittance advice, and several other messages. Each persona also has a few optional and conditional messages.

In addition to the core functionalities listed above, RTP has several other key messages that can be attached to RTP payments. One of the most important is Request for Payment (RFP), which is an optional message that enables clients to request payments. The RFP capability offers high value as a product offering within an FI’s overall RTP implementation. However, it does not provide the ability to pull funds from an account; instead, it is a push-only rail, which reduces the risk of fraud. If an RFP is accepted by a recipient, they then can initiate the outgoing payment.

Other RTP messages can contain remittance information or payment-related messages, such as payment acknowledgement or a Request for Information (RFI). This messaging capability makes it easier for senders and payees to match up information at every step of the payment workflow.

Business Benefits of RTP

Certainty – RTP removes the “unknown” element of transactions: a payment either goes through or it does not. With RTP, neither pending payments and debits nor payments in any type of incomplete status exist. The immediacy of RTP provides customers with a successful or rejected status within seconds, thus reducing calls related to the uncertainty of pending transactions and providing the FI with cost savings from reduced call volume.

Efficiency – FIs that implement RTP will see increased speed and efficiency in their customers’ money movement, and overall improved cash flow, as payments are only completed when account balances can support the transaction amount. Thus, potentially preventing overdrafts.

Consolidation – The RTP rail supports the attachment of data and other messages to payments. Extending messaging capabilities to what were once straightforward payments adds, adding value to transactions. Senders can include relevant payment details in a single package rather than in multiple forms or through different channels. One of those messaging types is a Request for Payment. RTP enables FIs to generate RFPs, which can either accompany a bill or invoice, or potentially replace it. Similarly, the ability to attach remittance messages automates Accounts Payable (AP) and Accounts Receivable (AR).

Equity – The RTP rail is fair and inclusive across the FI market. As the operator of RTP, TCH will remain a not-for-profit entity that will maintain the network and keep the pricing for participation the same for all FIs, regardless of size, TCH affiliation, or any other characteristics. TCH will not offer volume discounts, require transaction volume commitments, or impose monthly minimums. Considering TCH’s commitment to ubiquity and inclusion, even with the release of FedNow into the market, Levvel Research does not believe this model will change.

Business Use Cases for RTP

For FIs both large and small, RTP can facilitate various types of transactions between many different types of parties.

Corporate – Levvel Research predicts that the primary application of RTP will be for B2B, B2C, and C2B transactions, although a use case for individual P2P payments will likely strengthen as RTP matures. As the $25,000 transaction limit grows, more B2B applications will become commonplace in paying vendors, the automated receiving and reconciling of accounts receivable, and providing real-time cash management solutions for the B2B space. For B2C, disbursements will be a leading use case in the insurance and mortgage industries. For C2B, more immediate, integrated bill pay services will allow consumers to manage their bills in real time.

Retail/Consumer – P2P services have been at the forefront of the RTP conversation, and there are plans to use RTP as a transfer method for Zelle®. Levvel Research predicts that one of the most beneficial use cases for the retail/consumer segment will be through an enhanced bill pay experience. The FI will be able to offer more options for consumers to send and receive funds in their account by choosing the speed at which they wish to transfer funds. They can utilize current offerings and experience current processing times or choose to utilize RTP and receive or send their money faster. This is one of the only areas in which there may be room for FIs to charge for faster service, if the market holds that precedent.

Third-Party Service Providers – Levvel Research believes there are many opportunities for FIs, third-party service providers (TPSPs), and existing vendors that currently support the business payments ecosystem to quickly and strategically integrate the RTP rail. ERPs and other financial processing systems—namely AP and AR software—will face a significantly changed landscape for processing and managing business finances. For example, not only will RTP streamline payment processing for the software providers on the backend by consolidating payment files and reconciliation intervals, but it will also provide benefits such as faster payments, visibility into payment statuses, and messaging capabilities for AP and AR teams. Invoice and billing automation will take on a different meaning, as RTP essentially eliminates the need for traditional invoicing altogether by including much of the needed information with the payment itself. AP and AR software providers that support RTP sooner will gain a competitive edge.

How to Capitalize on RTP

There are countless use cases for RTP to enable faster, more efficient, more secure payments. The question for FIs is how to capitalize on those benefits. FIs have a unique position in the market to take advantage of RTP and to offer leading-edge products. If FIs choose to launch RTP with productization in mind, they will have the ability to look at the market from a fresh point of view, and create experiences that their clients need, as well as those that their clients have yet to consider.

Accounting and Finance Efficiencies – Partnerships with ERP, AP, and AR software providers may help streamline accounting tasks, but the automated processes are still complex and entail numerous moving parts, including separate workflows for invoice and payment reconciliation. In many cases, these providers are also conducting check writing and mailroom services to handle the remaining paper documents. If FIs partnered with these providers to create an RTP-enhanced process, the providers would gain efficiencies in their processing due to the ability to tie remittance data, such as the invoice number, purchase order, and other payor and payee information to the actual payment. These efficiencies would require less resources to accomplish the same tasks, and offer the potential for a faster, consolidated client experience.

Internal Operational Efficiency – Many FIs, even larger institutions, have processes that utilize manual or outdated resources. For example, an institution may recognize they are printing a check for deposit of a loan balance into a customer’s account. If replaced by RTP, the removal of the check handling cost produces significant savings. There may also be the opportunity to shift processes from batch to real time, which may allow a more robust customer experience, or even new, enhanced features to existing products.

Product Introduction and Enhancement – While introducing new products and enhancing existing ones should be a primary goal of an RTP launch, these products and enhancements should be based on portfolio and segment data to align with the needs of clients. There should also be investment into building proofs-of-concept and usability testing to create an offering that exceeds an organization’s clients’ needs.

Technology Modernization – FIs are already looking for ways to digitally transform by updating their technology, moving to the cloud, and refactoring their existing code base to new and more agile languages and approaches. RTP implementation will impact the organization as a whole and should be used as a catalyst to take large strides forward in transforming the FI to remain competitive in the current digital market.

RTP Adoption Challenges

Most FIs are considering adding RTP to their product offering at some point. Among financial institutions, especially those planning to wait five to ten years or more for RTP integration, adoption can be hindered by various business challenges. Despite the many benefits of RTP, FIs face challenges and risks when implementing RTP, and need to consider each when developing their strategy.

Resource Constraints – Organizations, especially smaller FIs, face resource constraints due to the high costs associated with implementation projects. Additionally, the systems needed to support RTP, including fee management and the user experience, are complex; this complexity is exacerbated by the nature of the financial services market, with challenges such as tax and regulatory compliance and account dispositioning.

Fraud Prevention – Adding a new rail inevitably introduces the risk of fraud, and organizations often act conservatively in order to manage it. Fraud affects all FIs, and RTP adds another layer of complexity to their existing fraud mitigation strategy. Most FIs do not have real-time decisioning for payments being sent, which does not allow them to effectively monitor or manage the risk of a real-time payment service like RTP.

Business Processes – Non-FI players—AP and AR solution vendors—may find it difficult to keep up with the changing market and be forced to roll out advanced updates to support the new rail. AP and AR providers may have to completely reshape their business models, as RTP will change the structure, requirements, and communication flows of traditional B2B payments.

Impact to Existing Revenue Streams – One survey respondent expressed concerns regarding how RTP would affect current payment processes: the “concept that RTP will cannibalize ‘other’ product revenue streams,” such as cash and check.

Low Perceived Customer Demand – While this had validity in the incipient stages of RTP, customer demand as a barrier is weakening; instant payments are fast becoming expected among FIs’ business customers. This is in large part motivated by the instant-money movement in the P2P space, such as Visa and MasterCard offering real-time options for card payments and instant money transfer applications such as Venmo and Zelle.

System Maintenance – Real-time payments allow for the end-to-end initiation and settlement of payments 24/7/365. The always-on technology requirement forces FIs to rethink their approach to system maintenance, as there is no “downtime.” Since many institutions have regularly scheduled downtime around which their internal banking processes are built, implementing the Receive and Send persona can be problematic for the current state, causing some institutions to hesitate.

Servicing – Servicing models will need to be analyzed and adjusted based on resources available, client expectations, and the degree to which RTP is automated as a service.

“Questions come back to the support model. If it’s 24/7, and if it’s real time, will you be supporting us operationally? Can we call somebody at three in the morning?”

Director of Product Management at a Top 250 Bank on changing servicing models for RTP

If an FI’s clients expect the level of service that warrants 24/7/365 support, that may need to be available for certain clientele. Ideally, the implementation of RTP is done in such a way that it is automated through digital channels and does not require any support considering it is removing the ambiguity from payments by providing a clear answer to whether the payment processed or did not. If the payment did not process, the client simply tries again after checking the information they entered is correct.

Vendor Support – An additional barrier for FIs is the sometimes-inflexible support model of third-party vendors. There are TPSPs in the market that have launched RTP products for FIs to use current products, cores, or front-end services. Implementation of RTP, however, may be limited until the vendor is able to supply the needed integration, updates, and front-end experiences required for RTP.

Many of the above barriers can be overcome through research and coordination with TCH to investigate the full capabilities of RTP, as well as thorough preparation.

RTP Adoption Groups

The general perception of RTP is that it is a progressive technology that will revolutionize monetary transfers and global payment processes. Despite this expectation, FIs are in different stages in terms of the extent of their adoption and enablement of the technology. Some institutions are taking proactive steps toward preparing for the rail, while others are waiting to see how it shapes the payments space. Based on interviews with financial professionals and survey data, Levvel Research has identified three groups into which most FIs fall in their RTP preparedness: First Wave, Second Wave, and Third Wave adopters (see Table 2).

* Data in this table represents averages or majorities; there are exceptions in each FI category.
¹ First Wave institutions are defined as having assets between $1 billion–$250 billion (or more).
² Second Wave institutions are defined as having assets between $100 million–$250 billion.
³ Third Wave institutions are defined as having assets less than $100 million for CUs and less than $1 billion for CBs.

RTP Alternatives

On August 5, 2019, the Federal Reserve announced its own version of real-time payments, the FedNow℠ Service. Like TCH’s RTP, FedNow will support 24/7/365 payments and settlements in the United States.

This new service will act as an alternative to RTP and to other money movement options with faster settlement speeds similar to TCH’s RTP network (e.g., cards and ACH). As a second option for real-time payments, this service alleviates concerns around economic security with TCH’s RTP network (e.g., network availability).

Depending on the use case, FIs will use FedNow, TCH’s RTP, or both. Currently, most large FIs use both TCH and the Fed for ACH transfers. Smaller FIs, however, may only adopt one or the other, as they typically rely on one provider for ACH. This difference in providers among smaller institutions will likely cause issues in ubiquity of a real-time service in the U.S. if interoperability is not quickly introduced. As of this writing, the Federal Reserve has stated that interoperability is not a priority for launching FedNow. For example, a sending institution will need to verify that a receiving institution is using the same real-time payments provider before a transfer or have a solution in place that makes the providers’ systems compatible. If the networks are not interoperable, real-time payments rails will face significant limitations and could cause confusion if FIs do not create a clear customer experience differentiating between the two rails.

Because TCH has a few years’ head start and greater than 50 percent of the financial services market, adoption of the FedNow solution may be tepid. The release of FedNow, however, might inhibit the adoption of RTP and its goal of ubiquity within the next few years.

“The Fed’s decision to interject in the launch and widespread acceptance of RTP has slowed the prioritization process to offer RTP across all business units.”

A Manager at a Regional Bank on the impact of FedNow on RTP adoption

Smaller institutions might opt to wait until the FedNow solution is available, even if they have intentions of launching a real-time service. Since the FedNow announcement is still relatively new, its effects will be seen in the outlook and decisions of institutions over the next six to nine months.

Data indicates that about 10 percent of FIs are waiting to see the Federal Reserve’s FedNow solution in order to compare with TCH’s RTP and determine which would be a better fit for their organization. With a projected FedNow release of 2023–2024, this strategy could put an FI at risk of falling behind those FIs that have chosen to implement TCH’s RTP.

RTP Market Trends

In July and August 2019, Levvel Research conducted an online survey including more than 200 respondents employed at U.S. financial institutions of all sizes1. This section summarizes the various RTP business strategies employed by U.S.-based FIs, including FIs’ internal and external plans and approaches to RTP development, timelines for adoption across different RTP personas, change management processes for transitioning to RTP, and customer segment engagement. It also evaluates FIs’ technical readiness and attitudes toward RTP.

Adoption Rates

When gauging RTP adoption, the data confirms that FI size plays a role. Figure 1 demonstrates the current implementation stages of large FIs across their customer segments, showing that the majority of large FIs surveyed, comprised primarily of First Wave institutions, either have gone live or are currently implementing RTP capabilities.

¹ For the purposes of this research, “large FIs” refers to national banks, foreign banks with U.S. subsidiaries, and investment banks, and “small FIs” are made up of credit unions (CUs), regional banks, and community banks. In some cases, Levvel Research breaks down the small FIs between credit unions, regional banks, and community banks. Customer segments are defined as consumer/retail, small business, and commercial.

Small FIs surveyed, comprised primarily of Second Wave and Third Wave institutions, are less likely to be live with RTP, and much more likely to still be considering RTP across their customer segments (see Figure 2).

Across all respondents surveyed:

• 74 percent reported that they are implementing or considering implementing across at least one of their customer segments.
• 17 percent reported that they have gone live across all of their customer segments (this group is largely comprised of First Wave FIs).
• Only 3 percent are not planning to adopt RTP in any customer segment.

Among FIs that are still considering or are not planning to adopt RTP (largely Third Wave institutions), the largest portion is credit unions. This is likely because credit unions may struggle to provide the resources necessary for an RTP launch and may be unable to support RTP as a product operationally after launch. There is, however, a clear business case for RTP among credit unions’ clients. For example, with the RTP Receive Only persona, a credit union that offers competitive savings rates could give its members the ability to immediately transfer funds into their accounts to take advantage of favorable rates as soon as possible. As in the case of credit unions, there are several ways that RTP enables financial institutions of all types to provide value to their members, and RTP adoption will only increase as more FIs identify these use cases.

Customer Segment Strategy

Customer segments play a substantial role in an FI’s decision to implement RTP, as FIs targeting consumer/retail, small business, and/or commercial segments will need to identify applicable RTP use cases for each segment. The following factors determine customer segment strategy:

• Simplicity – Overall, the FIs surveyed are more likely to implement RTP for their commercial customer segment first, likely because this is the most straightforward use case.

• Resources – While many smaller FIs are considering implementing RTP, they are not likely to launch to all customer segments at once, due to limited resources. They are more likely to launch RTP for the segment that most closely fits their portfolio; this is largely dependent, though, on how their routing and transit numbers (RTNs) are set up. RTP operates based on RTN, and if an RTN is live for Receive, every account within that RTN will be able to receive an RTP transaction.

• Third-Party Relationships – In the case of consumer banking, many smaller FIs rely heavily on third-party vendors for their digital channels, and most of these vendors do not yet have RTP on their consumer segment roadmap.

• Technical Design – The technical design involved with RTP plays a notable role in helping an FI determine which customer segments to focus on, as there is significant work entailed in building out the front-end experience (or customer portal) of the RTP interaction for the specific customer segment, as well as a large effort required to integrate all backend systems, including logic tied to posting, account types, and other requirements.

For the Receive Only persona, once an FI’s routing number is live, all customers in that routing number—commercial or consumer—will be able to receive an RTP. The only way customer segments may not be able to use the service on a Receive and Send RTP persona is if the front-end experience does not support the ability to present the customer with send functionality. The FI must build out the front-end experience required for the Receive and Send persona in order to launch that functionality. For example, there are specific notifications and data that must be presented to the client in order to offer RTP send as a capability, and those functions must be available prior to making RTP send live.

• Use Cases – FIs are building RTP products within segments with clear use cases. In some instances, FIs may not be aware of the ROI and value of RTP or underestimate its holistic impact on the payments space in the years to come. There are valid use cases for nearly every customer segment; enough time should be dedicated to identifying the opportunities in each segment.

When asked about the importance of RTP for their various customer segments, FIs managing $1B–$10B in assets indicated that RTP is most important to their commercial customers. This perception likely indicates that those FIs have commercial clients as their main portfolio, or that they only see commercial use cases for RTP. For these FIs, however, it is not a huge leap from serving the commercial space to serving small businesses, and RTP can be a perfect opportunity to expand their market. Banks managing $1B-10B are often trying to grow revenue, and one of the potential ways to grow revenue is to launch RTP.

RTP can be a strategic competitive driver. If most of a bank’s revenue comes from a specific segment, that is where it will initially focus, but what many FIs have not yet realized is the RTP functionality can be a valuable tool for both expanding product portfolios and growth in general.

Gap Between Strategy and Execution

In general, respondents hold a positive attitude toward RTP, believing that it will benefit their customers and give them a competitive advantage. While respondents indicated plans and motivation for RTP, though, a considerable portion indicated that their institutions are not currently equipped for it.

This is reflective of the gap between strategy and execution and may indicate that many organizations have not determined how to make RTP a reality in their institutions. This is confirmed by the results in Figure 4, which shows that FIs hold an increasingly positive outlook regarding RTP opportunities within their organizations over time

Another factor that affects the perception of RTP is the availability of other options besides the rail offered by TCH. Not all organizations surveyed expressed interest in whether the Fed would offer its own version of RTP (when this survey was conducted, the Fed had not yet announced FedNow).

According to TCH, many of the participating institutions are utilizing Receive Only capabilities (roughly 50 percent of domestic consumer demand deposit accounts are positioned to leverage the Receive Only persona). As FIs continue to assess the opportunity cost of pursuing more lucrative revenue-generating opportunities such as RTP Send capabilities, they will need to do so while considering FedNow as a future option.

Adoption Drivers

The main drivers that influence an FI’s decision to move forward are:

• Modernized technology
• Increased revenue
• Increased efficiency and decreased costs
• Customer demand

Business Drivers

When asked about RTP capabilities, attributes, and possible benefits that influence their own business operations and success, respondents value payment technology modernization the most, followed by the benefit of increased revenue (Figure 5). The focus on technology increases with size; FIs in the mid-market range ($100M–$10B in assets) are more focused on increased efficiency and decreased costs, while FIs with greater than $10B in assets are most focused on modernizing their payment technology overall.

One goal investment banks have for implementing RTP is payments cost reduction. There are several opportunities for savings through internal and external efficiency.

• Time – Some internal processes, such as ACH processing, currently take two to three days and often affect an FI’s ability to serve its customers in a timely manner. RTP reduces the time necessary to process a transaction, improving employee productivity by enabling them to serve customers more quickly, and ultimately increasing customer satisfaction. Efficiency across all transactions occurring within an FI increases as well, as organizations with an RTP integration will optimize their processes by updating their payments technology.

• Resources – One survey respondent explained, “I think the biggest benefit of RTP is the assurance of consistency across all payments platforms. Utilizing this technology negates the need for such a high FTE head count.”

• Streamlined Processes – An FI’s internal operating team may be paying service providers and customers with paper checks, which is the most expensive way to process a payment. RTP functionality improves cash flow for the FI and reduces highly tactical and unnecessary back-office expenditures.

• Increasing revenue, primarily from fee generation, is also possible with RTP. FIs can charge corporate customers for the new RTP service, as well as for RTP product enhancements for ancillary commercial products (e.g., reporting). FIs also gain revenue from per-transaction fees, which can vary by customer. Transactional fees can be applied to consumers who only process one payment at a time, while FIs can increase these fees for corporate and other customers making more payments according to the additional capabilities they would like to enable, such as nonfinancial ancillary messages like a Request for Payment or Request for Information.

These savings and new revenue opportunities can have a substantial impact on any FI and can even help drive growth and transformation for smaller FIs. One segment that is not likely to see this benefit is the retail segment. Consumers have an expectation of P2P, bill pay, and other services to be value-add services provided by their financial institutions, which will make it difficult to charge for those services, even using RTP.

Smaller FIs, or those with less than $100M in assets, are more focused on meeting customer expectations than larger FIs, which indicates they will develop RTP functionality based on demand. One survey respondent from a national bank said, “As a cross-border bank with operations in the U.S. and Canada, RTP and Canadian RTR are key for our product offerings.” For some FIs, especially those managing North American clients, there may be greater urgency to offer RTP as a payment option in order to better serve their customer base and to maintain a minimum standard of transaction capabilities.

When asked about other benefits of RTP for their business, respondents said that RTP provides the “flexibility in being able to deliver a more mobile and digital platform” and “the framework for future strategic implementations, such as cryptocurrency.” This forward-thinking, innovative approach to payments platforms sets an FI up for future potential revenue streams.

Customer Drivers

FIs ranked the real-time access to funds enabled by RTP as its most important benefit to their customers (see Figure 6). In general, FIs perceive the customer use case strongest when it comes to the RTP Receive Only and Receive and Send personas, as they do not rank the additional capabilities like Request for Payments and Request for Information of high importance. Efficiency and the opportunity to enhance the overall customer experience are top priorities for FIs.

RTP Implementation Strategies

Larger banks report that they have a clear strategy for RTP, while smaller FIs report that they do not. The strategy larger banks have, however, is likely a high-level plan rather than an actionable one, as many FIs struggle to productize RTP. This is in part because banks are treating RTP as a payment option to add to their product portfolio, rather than an opportunity to transform the customer journey. For example, instead of asking customers to choose between ACH, wire, or RTP modules, an FI should offer a single payment option and allow the customer to decide the price they are willing to pay based on the preferred transfer time frame and dollar amount to be transferred.

Strategy can determine the viability and implementation timeline of a bank’s RTP project. Approaching strategy with a customer-experience focus will enable organizations to build their own adoption plans and strategies with greater confidence. RTP strategies can take several forms: some FIs plan to implement using a phase-based approach, while others time the implementation with other major internal technology projects.

Phased Approach

In a phased approach, among the three components of RTP, Receive is most often implemented first. Rarely are all three set up at the same time. Like many First Wave institutions, Second Wave institutions are implementing RTP components in phases, starting with Receive. Some First Wave institutions have developed a Send and Receive persona with additional capabilities but have only turned on Receive functionality while continuing to build out the proper experience and operational processes.

Technology and time constraints are the primary reasons FIs select a Phased Approach.

• Technology is the greatest reason for a phased approach. It is much easier to receive a real-time payment than to send one, as there is no need to check funds availability, fraud scoring, or other reviews on a received payment—the sending institution is responsible for that. When sending a payment, the processing is much more complex and can be a struggle for many FIs. While many banks run on batch processing to do payment reviews, RTP would require them to process the transactions within seconds. This means they must develop new services to allow them to move from batch to real-time, which requires heavy investment in new infrastructure and ancillary support systems.

• Time constraints are key drivers for Second Wave institutions trying to go live as soon as possible to remain competitive with banks that are already live. Starting with the Receive Only persona allows them to get to market as soon as possible and participate in the rail. This can mean that strategies are built as they go and timelines are compressed. However, there may be unexpected advantages to adopting RTP after the First Wave. When asked about their organization’s turbulent implementation process, a representative from a small FI said, “We don’t have all the answers, but we are learning from experiences that the industry or other banks have had, as well as through forums and conferences. That, to me, is a way to educate ourselves, based on the earlier adopters, their lessons learned, the challenges they faced, and their success stories.”

Combined Approach

An advantage of RTP integration is the chance to plan a major technology upgrade at the same time. When asked about how they characterized that technology upgrade, 17% of FIs are planning a full digital transformation approach (see Figure 7). Larger FIs are much more likely to use RTP to drive other technology changes, as they are either planning or already executing a full or significant infrastructure upgrade while small FIs feel the upgrade will be more moderate. Respondents in higher-level roles at FIs, such as within the C-suite, were also more receptive to a full transformation approach.

In many cases, wider transformations are driven by the fact that other technology upgrades are necessary in order to successfully support RTP. Because payments are batch focused, in order to implement RTP, the internal systems need to support real-time versus batch payment reviews, batch account dispositions, and other components. Therefore, these internal requirements can lead to a full technology transformation in a bank.

The extent of the technology upgrade will often depend on an FI’s resources. The best-case-scenario is to holistically upgrade internal infrastructure during RTP integration—even systems and processes only tangentially connected to RTP. This helps to supports the ancillary functions of RTP capabilities and ensures scalability and long-term competitiveness in the market. If an FI implements RTP while upgrading only one element of internal systems, such as the user interface for the commercial customer segment, they are really only applying a stopgap solution that does not sufficiently support consistent competitive momentum.

Whether or not an FI plans a full technology upgrade depends largely on their ability to gain buy in for the project. Larger banks have the capital necessary for full technology upgrades, and the timing of the upgrades may align with the need to replace many other outdated systems supporting the entire organization. If the FI is already implementing RTP enterprise-wide, it is much easier to make a business case for a more holistic technology update project along with RTP.

With limited resources and larger barriers to gaining buy-in for internal initiatives, small FIs are more likely to seek approval for smaller projects rather than bundling RTP within a wider transformation project. Since small FIs are often just trying to get RTP to market, they plan to adopt only the Receive Only persona first so that they can become quick adopters. However, even when adopting only one persona, holistic technology updates are required to ensure successful implementation and prepare the organization to adopt other personas in the future. Coordinating a larger technology project while implementing RTP can be a good strategy for small FIs, because it offers a better chance for them to get approval for very important infrastructure upgrades. These FIs should continue to build out the full capabilities of internal ancillary systems as they move forward with adding Send to their capabilities, including real-time fraud monitoring, a full front-end experience, and target state operational processes.

The value of RTP for the competitive advantage of almost any FI is immense, and if an FI does not try to update their back-office systems along with an RTP project, including building out products for all customer segments, they will miss a great opportunity.

Strategies for RTP

Implementing RTP is no simple task, regardless of an organizations’ size or level of experience with innovative technologies. Informed by past success in preparing financial institutions for RTP, Levvel Research offers some key best practices and strategies to navigate this process for First Wave, Second Wave, and Third Wave adopters.

1. Identify the organization’s goals

The first step toward becoming an active RTP participant—prior to beginning any product development—is to identify and solidify the RTP goals for the organization. This typically starts with determining how RTP aligns with the strategic goals of the organization. For example, does the organization want to be known as a leading-edge FI, or is it content with following later in the adoption life cycle? Alignment on these goals will be paramount to acquiring buy-in for a large initiative like RTP.

Delaying RTP adoption involves inherent risks but may be the prudent strategy in some cases. As First Wave adopters release their RTP products and realize the benefits, there is a danger of falling behind in the market and losing out on a competitive advantage. However, for some FIs, the wisest choice is to delay implementation in order to prepare the organization, even if it will have to face the pressures of catching up to earlier adopters. A director of product management (DPM) at a top-250 bank stated, “When the larger players have taken that twelve to eighteen months for the ramp-up, I think we have our work cut out for us in terms of education and other challenges.”

In order to determine the optimal launch timing, FIs should undergo an Impact Assessment to fully understand the implications before, during, and after implementation, to establish their level of operational readiness. The outcomes of the assessment will outline the critical components FIs will need ensure its ready for launch. One Director of Product Management surveyed, stated, “I think the concern that most clients have is how this will impact their flows. How does it impact their systems, and what additional expense would they need to incur to support this?”

Technology providers are going to be the biggest help/hindrance in this process. Without the right technology implemented within our company, we will not be able to implement RTP properly and efficiently. All partners need to come together as one team to make the transition happen successfully.

Manager at a National Bank on how technology partners will aide RTP adoption

2. Design the Customer Experience

The potential impact to the organization by RTP depends on the expected customer experience being designed. FIs need to determine which capabilities of RTP make sense for its targeted customer base and business model. This entails gauging actual customer interest by evaluating current customers’ needs and any existing payment pain points. The design should be outside-in, where the RTP solution is designed from the customer’s outside point of view rather than the FI’s inside view of the organization and its processes. Stakeholders should come together in strategy sessions to map out what an RTP product would look like for their organization, including persona type, capabilities, pricing models, and integration with other products. These sessions should be followed by developing proofs-of-concept, which can include clickable prototypes. Clickable prototypes can be used in usability testing with clients to iteratively improve and refine an RTP product to ensure that it aligns with client needs and desires.

“We need to perform comprehensive and up-to-date consumer research to help inform our decisions.”

IT Professional at a National Bank on how to approach and incorporate customer needs

Strategy sessions should also cover how the organization would carry out their development and roll-out plans. The sessions are a way to collaboratively determine the feasibility of a project, identify when it could be executed, and gain consensus among all stakeholders.

A clearer view of their customers’ needs and RTP strategy allows FIs to plan and build their rollout timeline according to the reality of each customer segment. Instead of an immediate adoption of a full RTP persona and additional capabilities. In one research case, the DPM recommended a phased approach that was shaped by their customer needs and current operational readiness.

3. Determine technology needs

After an organization designs what the RTP experience will be for its customers—but before it can decide on its implementation approach—it must take a detailed look at its technology needs. The initial step is to take stock of its current payment processes, solutions, technology stack, and back-end service vendors, which may include the core banking system, fraud systems, and digital channels. It should also look at its processing and posting practices, which may be batch, delayed, or manual. In addition, the organization should identify the timing, frequency, level of automation, and interconnectedness of its payment processes.

A thorough analysis of internal processes will allow the FI to identify gaps in the technology. Gaps can be addressed by either a partner who supplies RTP functionality or a vendor with ancillary services (e.g., fraud monitoring, front-end experiences). If the FI has chosen to utilize a vendor to connect to the RTP rail, this deep dive will detail requirements that will need to be included in a Request for Proposal (RFP). The FI will also need to meet with current vendors that will be impacted by this implementation, such as core, digital channels (mobile and online banking for both retail and small business) and commercial portals. This will give the FI an early indicator of what gaps its current vendors will have and enable it to start the process of determining the timing and cost to make any necessary changes.

If the FI is interested in technology modernization, there should be an end-to-end analysis of current state architecture, code base, and application and systems to provide a holistic technological view of the organization. The FI will then be able to create a target state for each of those areas, form a roadmap to meet those goals, and identify key areas in which RTP can create efficiencies. This process can be done internally, but when external consultancies are used, they can bring unbiased and experienced viewpoints and identify opportunities that might otherwise be missed.

4. Decide on a development and implementation approach

Organizations should weigh the pros and cons on how they will approach the development and technical implementation of their RTP product. This decision will depend on an organization’s size, architecture, infrastructure, and any vendors’ existing RTP support. For many, it may be advantageous to utilize a third-party service provider (TPSP) or external core processor. According to Levvel Research survey data, the majority of FIs plan to use a third party (see Figure 8).

Another option for implementation is for organizations to connect to TCH’s RTP network with their own direct integration via a solution developed in-house. This option gives organizations more control and customization, as well as flexibility with TCH’s RTP product. However, because of the technical, resource, and budget demands of this route, fewer FIs (about 20 percent) choose to do it.

Direct or Third-Party?

The FI will need to evaluate internal resources and capabilities in order to make the decision on how to integrate. Whether the FI chooses to connect directly to TCH or through a TPSP, there will be architecture and development needs in order to launch RTP. Whether it is due to resource constraints or general uncertainty with implementing RTP, looking for guidance or technological support from a consulting partner could set the organization up for a more successful implementation.

There will be integration pain points, as neither option is a simple plug-and-play solution. Project teams will have to fill in gaps internally during a TPSP’s implementation or a homegrown product development, or they can leverage the experience of a consultancy. For instance, through a partnership with a consultancy, organizations can rapidly reshape their enterprise to meet new customer expectations by integrating RTP functionality into their product offerings. These joint deployment efforts can transform and develop stronger in-house capabilities, reduce vendor dependencies, and change how FIs operate overall.

In planning development and implementation, the FI will need to use the details discovered while determining the technology needs. They will need to review the following:

• Integration to the deposits core
• Customer and servicing channels
• Connectivity for RTP (directly to TCH or through a TPSP)
• Fraud, risk, reconciliation, and compliance
• Other technology systems (e.g., AML, OFAC, notifications for SMS/email)
• Operations
• Liquidity management
• Reporting, monitoring, and analytics

Each of these areas should be properly evaluated for any needed changes, as well as the need for additional software or vendor support. For the necessary changes, the timelines for each should be estimated and included in the overall implementation plan. Based on the persona chosen, the FI can then decide if they will choose a phased approach (Receive Only followed by Receive and Send, with Request for Payment optional) or an alternate approach.

The order in which changes need to occur is then determined based on which changes can be completed simultaneously. This should give a basic timeline of activities to be completed either prior to or in parallel to connecting to the RTP network with either TCH or a TPSP. The FI will then be able to work with TCH and/or their TPSP to determine estimates for connecting to the rail for implementation. Using this estimated timeline, the project team will be able to give stakeholders a high-level view of the resources and time commitment necessary to launch RTP as a product.

If the FI chooses to utilize a TPSP, preparation ahead of the RFP process is critical to producing an RFP package that contains requirements providing all necessary information and responses to adequately score each RFP participant. The following areas should be considered when creating the FI’s list of requirements for an RFP package:

• Does the TPSP allow easy access to data via APIs and data extracts, or does a user need to log into a vendor UI to view data?
  • If a user needs to log into a vendor UI to view data, will this meet all the requirements of teams that need visibility into RTP transactions such as fraud, AML, and reconciliation?
• What about internal data retention requirements for compliance and other teams?
• How can you monitor your liquidity operational messages? Can you receive messages from the TPSP or are you required to log in to the vendor’s UI?
• What type of deployment model are you seeking? Cloud? On-premise? Hybrid?
• How easily can the TPSP scale meet your expected volume demands?
• Does the TPSP control any decisions (e.g., fraud) where you want to control the final decision? Are they flexible to match your internal operating model?
• Does the TPSP offer flexible interfaces, such as an iFrame model?

Finding the right partner for RTP will be crucial to the success of not only the RTP initiative, but RTP as a product.

Stakeholders across the enterprise will inevitably be involved in an RTP undertaking, but it is critical to keep them all engaged throughout the project. The implementation process itself could use the waterfall method, with a more top-down approach, or agile project methods to keep development flexible and progress efficient. With either methodology, the project team should be flexible due to the inevitable uncertainty of an enterprise-wide project implementation like RTP.

For many, including those in the First Wave right now, partnering with a consultancy expedites their product release. A representative from an FI with more than $250B in assets explained: “One of the areas we would look for partners is anything that helps with the time to market.”

“Technology providers are going to be the biggest help/hindrance in this process. Without the right technology implemented within our company, we will not be able to implement RTP properly and efficiently. All partners need to come together as one team to make the transition happen successfully.”

Manager at a National Bank on how technology partners will aide RTP adoption

5. Address challenges and barriers

While implementing your RTP product, your organization will invariably face several roadblocks, even before a project officially kicks off.

Early education and awareness amongst stakeholders and decision-makers sets organizations up for success with any new product, and RTP is no exception. All levels areas of the organization from front-line and back-office operations to the board of directors should be aware of payment market trends and clearly understand the benefits of RTP. This understanding will drive internal support and adoption. It is important to realize that the stakeholders for RTP include groups beyond just product and technology, as its impact spans across all functional areas.

Resource constraints is one of the greatest barriers holding back FIs. The DPM emphasized the impact of these limitations: “How stretched resources are is the biggest challenge, along with—of course—the financial cost of replacing and upgrading, because these aren’t minor changes. These are huge changes, and the cost that we are looking at for each of these changes is tremendous.”

“These are huge changes, and the cost that we are looking at for each of these changes is tremendous.”

Director of Product Management at a Top 250 Bank on the challenge of resource constraints

Prioritization is the only way to move past a lack of resources and budget restrictions. Support from the C-suite and other organization executives is key to lifting any project off the ground, and sponsorship and a push from leadership leads to allocated funds. For a project of this scale, teams across an organization will require resources, including IT, operations, customer service, product, and engineering. Planning teams must pitch the value of each team involved, their part in the overall strategy of RTP implementation, and their needs for the project. Organizations should phase their implementations based on a consensus on the top-down directive for the implementation and the time to market they desire, coordinating logistics such as resource availability and sprint deadlines. Resource prioritization and organization will differ among FI types.

Conflicting priorities within any FI are natural, as every organization has many concurrent initiatives, and the limited supply of resources cannot meet the demand from every project. The DPM noted, “With U.S. banks, it’s regulatory and legal initiatives that we have to provide a large amount of the funding [for, including] Swift and ISO upgrades and other industry upgrades. Everybody’s fighting for that shrinking pot of dollars.”

Legacy systems are a significant barrier for FIs implementing RTP, and they continue to cause challenges downstream. The DPM said:

The challenge that most organizations have is that changes that are underway are radical changes. Most of the banks, like ours, have a fair mix of modern and legacy systems. Some of the changes that are applicable to legacy systems require expertise—and that expertise is shrinking; for example, there are very few COBOL programmers. So, the whole end-to-end analysis. Each time I have a team meeting, my only concern is, “Have we analyzed this end-to-end? What’s the downstream impact?”

Maintaining existing legacy systems is just as important as creating new solutions when transitioning into any product. Integration and compatibility should be a constant priority for RTP projects so that the new product will fit seamlessly and profitably within an FI’s existing business model. Existing software vendors should be thoroughly evaluated to determine what support for an RTP implementation they can currently provide, and whether the FI should engage with new vendors for the project. If the FI chooses a new vendor to provide RTP, it will need to ensure that the new and existing vendors are able to work together effectively.

Access to vendor data is another potential challenge. FIs must be able to access all of the data needed in order to process payments in real-time. For example, do the vendors’ fraud systems support real-time fraud checks? What required messaging for RTP will the vendor handle versus what will be handled by the FI? How flexible is their solution? Can it accommodate any custom workflows you have in place or may otherwise need?

The FI project team should keep in mind that with all enterprise-wide initiatives, changes and delays are inevitable. The DPM offered a glimpse into the type of timeline changes that can occur, and the approach with which their organization responded: “We had some technical delays, so we are going live in phases—as I think most banks have, and will do going forward as well. It has caused us to miss our deadlines by a couple of months.” Because these types of unforeseeable delays should be expected, FIs should carefully consider phased approaches to implementation and keep project plans flexible.

The organization will need to maintain accountability on goals set for the RTP launch. For example, if the FI planned to modernize its technology, that plan should not be abandoned when issues arise during the RTP implementation. Also, the FI should manage RTP as a true product by evaluating the constantly changing market and adjusting RTP as a product accordingly.

Conclusion

The momentum behind faster payments is building in every market where it has been rolled out, fueled by growing customer demand. FIs need to anticipate future customer demand and seize the opportunity to invest in real-time payments. Creating a future focused RTP strategy requires getting started now.

Smaller FIs are faced with challenges around technology and resources, knowing RTP is not a plug-and-play solution. Successfully implementing and leveraging RTP will take a clear strategy, and FIs that rise to the challenge and embrace the transformation will gain a competitive advantage. The implementation journey will be an educational one, and the outcome will be a stronger, nimbler, and more technologically advanced FI. As one survey respondent put it: “I think the learning never stops—and that, to me, is the most exciting part.”

About Levvel Research

Levvel Research, formerly PayStream Advisors, is a research and advisory firm that operates within the IT consulting company, Levvel. Levvel Research is focused on many areas of innovative technology, including business process automation, DevOps, emerging payment technologies, full-stack software development, mobile application development, cloud infrastructure, and content publishing automation. Levvel Research’s team of experts provide targeted research content to address the changing technology and business process needs of competitive organizations across a range of verticals. In short, Levvel Research is dedicated to maximizing returns and minimizing risks associated with technology investment. Levvel Research’s reports, white papers, webinars, and tools are available free of charge at www.levvel.io.

Disclaimer

All Research Reports produced by Levvel Research are a collection of Levvel Research’s professional opinions and are based on Levvel Research’s reasonable efforts to compile and analyze, in Levvel Research’s sole professional opinion, the best sources reasonably available to Levvel Research at any given time. Any opinions reflect Levvel Research’s judgment at the time and are subject to change. Anyone using this report assumes sole responsibility for the selection and / or use of any and all content, research, publications, materials, work product or other item contained herein. As such Levvel Research does not make any warranties, express or implied, with respect to the content of this Report, including, without limitation, those of merchantability or fitness for a particular purpose. Levvel Research shall not be liable under any circumstances or under any theory of law for any direct, indirect, special, consequential or incidental damages, including without limitation, damages for lost profits, business failure or loss, arising out of use of the content of the Report, whether or not Levvel Research has been advised of the possibility of such damages and shall not be liable for any damages incurred arising as a result of reliance upon the content or any claim attributable to errors, omissions or other inaccuracies in the content or interpretations thereof.