The State of Faster Payments in the U.S.
Obstacles, Innovations, and the Road Ahead
The U.S. has five payment rails — ACH, Zelle, FedWire, cards, and the newest rail, RTP¹. Each rail has an infinite number of nuances and complexities associated with it and is generally only appropriate for specific use-cases. In this report, we focus mainly on ACH, Zelle, and RTP, as these offerings compete for faster payments and have come a long way to improve user experience. While much advancement has been made, anyone with experience using these rails knows there is still a lot more to do before all of the friction is gone.
Introduction to Payment Deployment
Consumers and businesses have several options to move money:
- ACH
- Zelle
- FedWire
- Network rails (Visa, Mastercard)
- RTP by TCH
The U.S. has been innovating on payments for over 100 years, starting in 1918 with FedWire and culminating with the Fed’s forthcoming introduction of FedNow for real time payments. In this time period, three more payment rails were rolled out featuring faster speeds, better consumer experiences, and new modalities. However, with more opinions, FIs² have had implementation challenges that led to the rise of what has become known as payment hubs.
Payment hubs were deployed to connect the disparate payment rails with core banking infrastructure. These hubs were deployed alongside legacy technologies which served their purpose when originally implemented, but as the world shifted to open-banking and a heavier reliance on APIs, these hubs have become outdated.
Modernizing these payment hubs has been critical to deploying RTP and will require FIs to invest in real-time compatibilities. These hubs should be cloud native, API first, and support data creation/analysis from the ISO 20022 message type. This modernization effort will also allow them to scale to global schemes, whether batch-based or real-time — more on that later.
The most ubiquitous payment rail in the U.S. is one that is responsible for $62 trillion in volume across 25 billion transactions — ACH.
ACH
ACH stands for Automated Clearing House, which is a bank network to move money. NACHA, the National Automated Clearinghouse Association, creates and maintains the rules that regulate fund transfers between these banks. Most people don’t realize this, but 80% of electronic payments are done through ACH rails.
How ACH Works
There are 2 basic ACH flows — credit and debit. Debit transactions involve having money pulled from an account while credit transactions involve having money pushed into an account. This difference has huge implications for the risks of transacting through ACH and is why there is so much friction in the rail.
The ACH network is an intermediary between ODFIs (Originating Depository Financial Institution) and RDFIs (Receiving Depository Financial Institution). A business that wants to send or receive ACH needs to work with a bank that can serve as the ACH originator, or ODFI. When a user initiates a transfer, there is a NACHA-formatted file that gets created. The ACH file format (or NACHA file) is a 94-character long record to execute domestic ACH payments through NACHA and the Federal Reserve.
ACH is batch-based, which means that NACHA sets certain daily cutoff times to settle transactions. The first submission deadline is at 10:30 AM ET, with settlement occurring at 1:00 PM ET; the afternoon submission deadline is at 2:45 PM ET, with settlement occurring at 5:00 PM ET. If a transaction falls outside of the two time periods, the settlement occurs the following day.
ACH Limitations
The ACH rail is prone to various return codes, the most common of which is NSF (Not Sufficient Funds), which happens when an ODFI tries to pull money from the RDFI, but there is an insufficient amount of money in the account to cover the transaction. Furthermore, ACH is prone to reversals for up to 60 days. There are 85 different error codes that could cause a reversal. Here is the full list.
Today’s Pain Points
Push vs. pull transactions come with very different risks, but let’s begin with the most common difference. Most push transactions come in the form of direct deposit or government disbursements. Pull transactions make up the majority of ACH transactions with certain exceptions.
Here’s the nuance — almost all fraud is on ACH Debit (“pulling” funds from external accounts) since the RDFI can send back a NSF or fraud return code when the ODFI already credited the account. This means that an autopay transaction can pull funds from one’s bank account even if they’re not available (putting the user into overdraft). This subtlety perpetuates a blind spot for institutions — one that enables banks to charge billions of dollars in overdraft fees as well as ACH return fees.
Companies like Robinhood and Coinbase have tried to solve the issue of NSF by applying credit scoring algorithms to individual customers. As a user, one might notice the availability of instantly tradable funds on these platforms even though the money from their bank account does not clear until several days later. How does this happen? Robinhood essentially builds out internal models to predict NSF risk. If the chance of said risk is low, Robinhood loans money to the user for the amount of time it takes the company to retrieve the money from the user’s bank account. In the name of great user experience, Robinhood takes on credit risk. The amount of money that Robinhood is willing to risk wholly depends on historical user transactions transferred into the Robinhood accounts. Some users have access to $500, while others have access to as much as $50,000.
Similarly, Chime has productized early access to direct deposit because they have visibility into the NACHA file from the user’s employer up to 2 days before it hits the user’s account. Because it is a push mechanism, it’s a risk free loan that Chime can provide. With RTP, this feature goes away, as the user receives funds instantly from their payer.
Companies like Orum have democratized access to the real time risk engines that score the probability of payment success. Orum can calculate the probability that a customer will receive money from an external account — essentially giving customers access to a Robinhood-like credit scoring model, but “as-a-service.”
Closing Thoughts
The ACH network has been around for almost 50 years and is a staple of how we move money, so much so that FI core infrastructures were built to support the technical specification of the rail. Recent innovation has come in the form of increased transaction limits and added settlement windows, so while it’s not real time, it fills the gap for most use cases. However, as consumers and businesses require faster payments and modalities, Zelle and TCH were created for when more immediacy is needed.
Zelle
Early Warning Services, owned by the largest 7 banks, operates the Zelle network. Most users are familiar with Zelle as the peer-to-peer payment app that allows users to send micro transactions (generally between $1,000 and $5,000 depending on the FI). In fact, the average transaction size is roughly $270.
While initially positioning itself as a peer-to-peer service, Zelle has been dedicating more resources to service small and medium-sized businesses (SMBs) and marketing faster payments with less reliance on checks. For SMBs whose primary services fall within their FI’s allowable range, Zelle facilitates improved cash flow and ease of use. However, the vast majority of FIs have not implemented Zelle for their users.
Zelle has also recently been the only option to mimic real-time payments even though in reality, transactions settle via ACH in batches. This user experience has been a preamble to RTP, the real-time gross settlement money rail.
Now that we have talked about faster payments vis-a-vis ACH and Zelle, let’s turn to real-time payments — the latest innovation in the sector.
RTP
In 2017, a consortium of 24 banks called TCH (The Clearing House) launched RTP. The goal of TCH is to bring instant, irrevocable payments to its users — a phenomenon that is ubiquitous in the rest of the world, but was not in the U.S. The RTP rail uses the ISO 20022 message type, a nuance that we will touch on later.
- RTP is a way to push money within seconds by sending money directly to a bank account offered by TCH. Today, 70% of DDAs (Demand Deposit Accounts) are enabled to receive money via RTP.
- RTP is a push-only transaction, meaning there is no risk of NSF, which is a big problem with ACH.
- Cost is capped for the banks at $0.045 per transfer. The banks then mark it up.
RTP was launched out of the need for quicker settlement times. According to Volante, above all else, FIs seek faster payment capabilities.
How It Works
When a bank joins the TCH network, it is responsible for posting collateral, known as CPP (Current Prefunded Position). A sending FI’s transactional deposit range determines how much CPP it needs and how much it can potentially send. If the amount sent is greater than the CPP, the RTP system rejects the payment. If the CPP is sufficient and all other checks are valid, the sending FI’s CPP is reserved in an amount equal to the payment.
Payments get debited and credited instantly from an institution’s balance with TCH. This settlement mechanism allows for instant, irrevocable payments.
The RTP transaction begins when the sending FI receives instructions for a payment, which creates an RTP payment message that is sent to the system for network routing and message content validation. The payment can either be accepted, rejected, or accepted without posting. When the RTP system receives the “accept” response from the receiving FI, it debits the sending FI and credits the receiving FI. The receiving FI immediately posts the funds to the user’s account and makes the funds available. The diagram below illustrates the path a payment takes between receiving and sending FIs.
For FIs that have receive-only capabilities, which is quite common, there is no need to prefund the joint settlement account, as they don’t have sending capabilities. This also prevents them from fully participating in all of the benefits that RTP offers.
What RTP solves
RTP use for businesses
RTP solves some major challenges businesses face when sending and receiving payments. NSF risk is a well known issue with ACH and one that TCH wanted to solve in their payment rail. As such, a crucial advantage of RTP is decreased probability of a payment reversal due to it being a “credit-push” transaction, which requires the sender to have the necessary funds in the account in order to make the payment.
Corporations can optimize their cash flow thanks to RTP and its fund settlement that occurs in mere seconds. Companies being able to receive payments instantly means an increase in cash and a decrease in cost of working capital. A July 2020 survey by Mastercard found that SMBs acutely demand real-time payments, which makes them more sensitive to antiquated payment modalities such as checks, and increasingly, ACH.
Businesses can also decrease costs and operational requirements of basic back-office processes like AR and AP due to the adoption of RTP.
Rapid settlement of funds allows suppliers to immediately ship materials that require payment in advance of shipment. Instead of waiting for payments to settle, the supplier receives the money immediately and can process the order and ship the product right away.
Other use cases include any account-to-account transfers and real-time payroll.
Startups that Offer Real-Time Payments
Fintechs aren’t asleep at the wheel — they understand the value of real-time payments and have had innovative, modern solutions to bring the product to their customers.
RTP Use for Consumers
Consumer-related use cases include compensating gig workers after the completion of a shift. Today, Uber and DoorDash largely solve their payment needs via push to card — this method is quite expensive because it’s based on card interchange fees. When marketplaces that employ gig workers switch to RTP, they can both significantly bring down costs and improve user experience. This is mainly because RTP allows for immediate account-to-account transfers, which can reduce costs, save time, and allow for money to be sent 24x7. Furthermore, studies have shown that one in four consumers would switch financial institutions to access real-time transfers. And almost 90% of gig workers would opt for a platform offering real-time payouts at the end of each shift.
Even though the benefits of RTP are quite clear and well documented, implementation doesn’t come without its challenges. The primary issue revolves around outdated FI infrastructure and old messaging systems that can’t handle the increasing volume of metadata associated with RTP.
Current Infrastructure Challenges
As FI’s think about rolling out RTP, several nuances prevent them from being able to immediately deploy the technology. The first is core compatibility with real time processes, and the second is lack of infrastructure around the extraction of insights that FIs can gain from supporting the payment type. Institutions have found a way around solving both of these challenges without ripping and replacing legacy core providers, however the solution isn’t clean. Therefore, near term innovation will likely occur on the orchestration layer rather than the core layer.
FIs seeking to integrate with RTP should be aware of some key operational differences between RTP and ACH.
Moving from batch to real time. This shift isn’t unique to FIs integrating with RTP, as customers across many different sectors expect more and more elements of their business operations to occur in real time. FIs will need to update internal processes to support real-time payments.
Irrevocability of RTP. Once money is sent using RTP and both participating FIs accept the credit transfer, the money has moved. On the bright side, the permanence of the transfer means that FIs no longer have to take on the hassle and cost of reversals.
Credit push only. RTP doesn’t offer an equivalent to ACH debit, which alleviates the risk of overdraft and return fees.
Transitioning from batch-based to real-time
Prior to RTP, most payment rails worked on a batching system. A batch process aggregates all outstanding payment flows and settles them in intervals during the day. Because a large part of the payment infrastructure in the U.S. works on some sort of batch process (ACH, Zelle, etc.), core infrastructure was built to support this workflow.
Until core infrastructure supports real-time processing, institutions need to rethink processes and workarounds to send and receive real-time payments. Whether using a middleware, payment hub, or something similar, an abstraction layer will be one of the ways to deal with the complexity of underlying implementation as new payment capabilities are added. These solutions emulate a real-time response, but actually batch transactions back to the core.
In addition to payment processing, FIs need to think strategically about the data that is sent with the payment. RTP utilizes the data-rich ISO 20022 message type, which requires some systematic improvements to leverage fully.
ISO 20022
ISO 20022 is an international common standard by which metadata related to payments and other financial transactions are transferred between financial institutions.
There are many added benefits of adopting ISO 20022 including richer, more consistent data, streamlined interoperability, full originator and receiver information, and the ability to create new products and services.
According to Finextra:
Analysis of the data can generate valuable insights to drive development of new payments products and features. This is especially valuable for corporate finance professionals in areas like AP and AR, with that data offering support for spend analytics, automated reconciliation and other insights.
Today, ISO 20022 isn’t fully adopted across all financial organizations, however there are aggressive timelines in place to migrate laggards who haven’t prioritized this adoption.
Challenges to adopting ISO 20022
FIs can take two paths to adopting ISO 20022 — translating or converting. The main difference is that the former is significantly quicker and banks who are pressured by the global ISO timeline may be tempted to go that route. FIs have the option to use translation tools which enable them to interpret messages sent and received in the new standard. Most FIs use their core providers for the translation service. However, in addition, SWIFT has developed a translation service via API. The drawback is that not all of the data that ISO 20022 transmits gets captured, which prevents banks from analyzing and productizing this data.
The main challenge for full conversion is prioritization — because banks have numerous internal projects related to everything from cloud migration to core modernization, adding another highly complex and time intensive project in parallel poses a challenge.
With Current Technological Challenges, How Do FIs Implement RTP?
There are two ways that an FI can implement TCH RTP:
Connect directly to the TCH network. This is a complex process that requires a high level of expertise. The steps involved include adjusting internal company processes and running tests on functionalities.
Connect to TCH via a Third-Party Service Provider (TPSP). More than half of FIs that have less than $15 billion in assets prefer to use a trusted TPSP because they lack the requisite internal resources to update their backend processes to be compatible with RTP. Most FIs leverage TPSPs because these service providers handle more than just connectivity to TCH; they are equipped to conduct message format and syntax validation, interact with intra-organizational systems, and provide access to logged messages through an operational dashboard.
In either case, there are certain infrastructure improvements and conditions that institutions should keep in mind as they think about implementing RTP including, but not limited to, liquidity management, operational improvements, and actual orchestration.
Liquidity Management. As part of supporting RTP, FIs should think about liquidity management changes vis-à-vis new workflows. Operating 24x7 means that banks must set up automated wire transfers for their CPP with TCH — this may require reserve management, as there is less predictability around cash flow needs.
Architectural Evaluations for FIs. FIs must adhere to RTP’s service level agreements (SLAs). One such example is RTP’s requirement for response times to be under 5 seconds. Carrying out a performance budget analysis focusing on flow that directly impacts TCH’s five-second SLA is essential; the longer the chain of critical systems involved, the more challenging it is to meet the SLA.
RTP Integration Phasing. Integration with RTP may seem like a daunting task for many FIs, as it is the first truly unique payment rail in the U.S. in over 40 years. It may help to break down the integration into phases.
Receive-only. This phase covers account validation and fraud checks. Once an FI receives an RTP credit message, it must respond back to TCH within 5 seconds indicating whether it wants to accept, reject, or accept without posting.
Send. This phase involves real-time account validation as well as real-time fraud checks. There are many questions for a FI to consider at this point, including: can the FI’s fraud system ingest data in real time and score that data to help weed out fraud?
Send can be broken down further by considering the type of client the FI wishes to support first; it can choose to enable RTP Send for commercial customers first, followed by SMBs, and finally for retail clients.
So where does all of this leave us?
Real-time payments are here but the majority of FIs have failed to make integration a priority even though it’s a product their users want. There are several reasons for the slow implementation including education, technical infrastructure, and a general wariness of TCH.
Education is a major inhibitor of real-time payments deployment. Scroll through the websites of most FIs and it becomes clear that user experience is not top of mind for these institutions. Just as the onboarding experience is stuck in the early days of the internet, so too are the payment options that customers have. This lack of awareness has stymied FI’s initiatives to upgrade their payments system.
FIs internal infrastructure isn’t up to date to send real-time payments. Even if FIs are cognizant of the need to implement quicker payment schemes, many are incapable due to legacy infrastructure that prevents them from deploying newer rails. And given that the payments space is just one piece of a strategic roadmap for FIs, their customers will likely have to wait for some time before seeing a meaningful improvement in functionality.
FIs know that FedNow is on the roadmap. Some FIs have politicized TCH and haven’t bought into the egalitarian nature of the ownership group. As such, many FIs are waiting for the 2023/2024 rollout of FedNow; most FIs already have a relationship with the Fed via FedLine, so a new modality through the Fed is the path of least resistance.
Some ACH volume will get cannibalized by RTP. Customers will start migrating their ACH workload to RTP. This is increasingly driven by customer demands as we live in a world where other services are available 24x7.
Regardless of one’s stance on the state of payments today, one thing is certain: there are significant tailwinds behind faster payments in the U.S., be it through legislation, council formation, or FIs’ prioritization of system upgrades.
¹ A registered trademark of TCH (The Clearing House)
² In this report the reference to FI (financial institution) is generally in relation to community and regional banks, which usually rely on third party infrastructure — national banks have custom processes and systems to support their payments operations.