To understand where real-time payments are going, it’s important to understand what they even are. One of the biggest misconceptions is that real-time payments networks move money instantly. After all, when someone receives a real-time payment, and their account balance instantly changes, there’s somewhat of an optical illusion that money has traveled in real-time from sender to receiver.

Ledger-Based

One of the biggest misconceptions is that real-time payments networks move money instantly. After all, when someone receives a real-time payment, and their account balance instantly changes, there’s somewhat of an optical illusion that money has traveled in real-time from sender to receiver.

‍

In every iteration of a real-time network, money doesn’t move in real-time, in fact it doesn’t move at all. Rather, the core of the network is based on a simple accounting principle, a ledger-based infrastructure where two participating institutions, a sending one and a receiving one, interact with a pre-funded centralized account that records each institution’s position.

‍

In other words, real-time payments behave less like a text message traveling through networks and waves, moving from origin to destination, and more of like a spreadsheet, recording numbers and making calculations in real-time.

‍

In the US, one of such networks is the “Real-Time Payments Network” aka “RTP®”. When a sender and a receiver exchange money, and each of them hold accounts at separate participating institutions, each bank’s change of cash position is recorded at a shared centralized account at the Federal Reserve that each bank has pre-funded. The sender’s bank is recorded a negative transaction, the receiver’s bank is recorded a positive transaction, money never traveled, all that changed were the digits that appear on the sender’s and receiver’s balances. A simple accounting exercise.

This concept, although simple, to me is the single most important concept to understand in order to formulate an opinion about the future of real-time payments. Its ledger-based infrastructure is central to the ecosystem’s opportunities, challenges and complexities for adoption and expansion. Specifically, because of their impact on liquidity and reconciliation.

US, MX and CA graphic and Explanation

Conversational

So why can’t traditional networks do this simple accounting exercise? The piece of the infrastructure that allows for an instant settlement lies in its messaging capabilities. Historically, payment flows have been single-directional, lacking any type of immediate feedback, only two outcomes can occur: (1) success is assumed when no response is received, (2) failure is captured when a payment is returned. They lack the capability to support any type of error resolution.

Instant payments introduce a conversational format, an immediate response is capable of validating the receiving account, and confirming the acceptance and settlement of the transfer. This in turn enables financial institutions to confirm settlement in real-time.

This change from single-directional to conversational communication is the beating heart of the innovation that are real-time payments. As with any other innovation, it introduces its own set of complexities and challenges. These “conversations” impact different sides of the operations of a financial institution and requires them to meet 15-20s SLAs on a 24x7x365 basis, no easy feat.

Push-Only

Real-time payments are Credit Push which means that only the sender of the payment is able to instruct its financial institution to make a payment. This is a key aspect of real-time payments as other networks allow for what is called a Debit Pull in addition to a Credit Push, a pull allows the recipient of the payment to initiate the transaction instead of the sender. This capability enables payment experiences we’re very familiar with these days and allows for a frictionless experience. Think any subscription, or the auto payment on your credit card, these are experiences that allow the user to be entirely hands-off, a more convenient experience.

As with many things in payments, there are two-sides to this coin:

• Pull capabilities can bring convenience and frictionless experiences, but can also make these payments more susceptible to things like chargebacks and fraud, because the network allows for transactions to occur without a final approval or even review from the account holder. For this reason, they can get messy more often as the account holder may not recognize the transaction for a plethora of reasons, some fraudulent, some not.
• Push-only capabilities bring a layer of security as the network requires the user to make a final approval to any transaction before it can be executed, which means a user is much less likely to not recognize a charge, leading to less chargebacks and potentially less fraud, but it also introduces a layer of friction that the modern user has come to not expect.

Whether push+pull or push-only is better is a matter of perspective. What do we hold dearer, security or a frictionless UX? This is were diverging views begin to arise, for an e-commerce merchant focused on conversion, a frictionless UX will win every time. For a bank that sees itself as the first line of defense, security will be top of mind. For consumers, it depends on who you ask, and which scenario they think about. It’s all speculative. What is real is that a push-only network introduces a behavioral shift if it is ever to serve all types of payments. A term I’ve personally come to loathe, because behavioral changes are hard to accomplish, and they take a long time to shape. With the right inceptives though, they can happen.