Part II - The Why and How

Why does real-time matter?

All-day, every-day real-time gross settlement

First, real-time gross settlement (“RTGS”). What is it? Breaking it into parts, we have real-time and gross settlement. Real-time settlement is when payments’ clearing (sending the message) and settlement (moving the money) occur more or less concurrently. This is in contrast to deferred settlement that happens on a set schedule, e.g. EOD. Gross settlement is when settlement happens on a transaction-by-transaction basis. This is in contrast to a net settlement basis where payments are batched together and netted to grand totals. For reference, ACH and same-day ACH are deferred net settlement systems.

Putting it together, RTGS is a model where there is continuous clearing and settlement of funds on a payment-by-payment basis. RTP and FedNow are the only faster payment systems in the US that will offer RTGS 24x7x365.

With RTGS, a transaction will only be completed if the originating participant has an adequate balance in its account. Credit risk between participants is therefore eliminated and real-time settlement enables immediate finality of all payments. However, demands on liquidity and thus liquidity risk in this model are higher. One of the major differences between RTP and FedNow, as noted in Part I, is liquidity management. Let’s look at each.

Settlement in RTP is done through a fully prefunded account at the Fed that is jointly owned by all the participating FIs. Basically, a pooled account where RTP keeps a ledger of the participants’ balances. RTP will verify a sender has a balance large enough to cover the payment before forwarding the payment to the recipient. This eliminates settlement risk. If a sending participant does not have a large enough balance to cover a payment, the payment will be rejected. Overdraft and negative prefunded positions are not allowed. This works pretty well but, how do these 24x7x365 settlement accounts get prefunded you ask?

Through FedWire. During FedWire operating hours. So banks have Monday-Friday until roughly 7pm each day to figure out liquidity needs to ensure they have a large enough balance 24x7x365 otherwise payments halt. Cool. To create a buffer, TCH requires sending banks (receiving only banks don’t have this requirement) to hold a minimum balance in their account. Talk about a treasury treasury management nightmare. Have you ever wondered why so few banks are enabled for RTP send compared to receive? This is a big reason why. Time for some self-soothing with the RTP flow of funds diagram:

FedNow’s settlement and liquidity solution is better. That is the benefit of launching second - you get to learn. With FedNow, settlement occurs in a FI’s master account. This has a few benefits: 1) the funds count toward reserve requirements; 2) they can earn interest; and 3) the FI can access borrowing options to support liquidity needs. The Fed is launching a “liquidity management tool” that will be available to FedNow participants, their liquidity providers, and even RTP participants. In the meantime, TCH is solving some of these issues with bilateral credit agreements between banks to provide borrowing facilities, but it is not as good as being able to access the discount window or the full balance in your Fed master account. The Fed wins this round. More pretty diagrams:

New data, new opportunities

Now, let’s first talk about messaging. ISO20022 is pretty exciting. ISO20022 is a new payments messaging standard that was released in 2004 and has been slowly making its way through payment systems. Today, 70+ systems use it globally and others are in process, including SWIFT (Nov 2025 deadline) and FedWire (now 2025 deadline, recently delayed from 2023 to 2025).

You can think of ISO20022 as a new common language payments receivers and senders use to talk to each other. For card people, think ISO8583. Historically, each FI developed and used their own standards, their own language. Without a shared language across payment systems, both domestically and cross-border, it was nearly impossible for FIs to communicate effectively with each other. ISO20022 helps solve this and is an important step towards a universal standard, paving the way for payments interoperability. Yet, it still allows easy customization by FIs for their specific needs. This last point may actually limit true standardization. For example, ISO20022 is not perfectly consistent across rails (SWIFT, FPS, SEPA, RTP, FedNow, etc.) and different banks will use fields differently but it is still a lot better than what we have today. Not only that, but the data opens new doors.

Technically, ISO20022 uses an extensible markup language (XML)-based syntax, which allows for greater data volumes and customization, makes parsing financial information easier and prevents potential truncation and data loss. Basically, you can add way more information to a payment compared to what we have today. ISO20022 increases the number of data points one can add to a payment from ~100 to nearly 9k characters. This can allow for improved fraud prevention and compliance, easier investigations, and improved straight-through processing rates. ISO20022 also allows for non-value message types and request for payment messages.

Potential for financial inclusion

With real-time payments, businesses and consumers could have full access to their funds immediately, giving them greater flexibility to manage their money and make time-sensitive payments. With 3 in 5 Americans living paycheck to paycheck, this is a big deal.[1] Today, there is an entire industry built around filling the multi-day time gaps in the ACH system, which payroll and even Department of the Treasury payments use. Payday lenders, check-cashing stores, and a handful of fintechs (Dailypay, Dave, Earnin, Payfare, PayActiv, and more), effectively offer bridge loans at high interest rates (some worse than others) to help bridge low- and middle-income people in the US through to when the payment actually hits their account. For consumers, early wage access and faster disbursements could mean hundreds of millions saved in overdraft fees and interest expense every year. For businesses, access to funds in real-time could mean faster working capital cycles for SMBs and no clawback risk.

Catching up with the rest of the world

The US is woefully behind other countries. 80 countries have real-time payment schemes but adoption varies.[2] Major successes have been Unified Payments Interface (“UPI”) in India and Pix in Brazil. UPI was launched in 2016 and was built by the National Payments Corporation of India (like TCH) and is operated by the Reserve Bank of India and the Indian Bank Association. UPI was launched specifically for mobile transactions given the low banked population in India as well as limited online/internet activity. Today, more than 300 FIs have joined the network with over 200 million transactions combined per day.[3]

Underlying UPI is the India Stack and Aadhar, the government-mandated biometric identity database (with over 1.31 billion Indians enrolled) that enables low cost verification and limits payments fraud. The US has nothing to rival India Stack and something tells me a government-mandated identity database won’t make it through Congress (although Clear is succeeding in airports, one holiday referral code at a time). Also, UPI’s open architecture and direct access provided to fintechs facilitated the adoption of real-time payments apps such as Paytm, Google Pay, Apple Pay, and PhonePe (and their latest eye-popping round).

We also must talk about Pix in Brazil. Launched in November 2020, Pix has exceeded all expectations. Over 75% of adults in Brazil have sent or received a Pix, 60% of merchants have joined, and overall it is the fastest growing national real-time payments system in the world.[4]

There has been a lot written about Pix comparing it to the potential of FedNow (a personal favorite is A16Z’s piece). Credit to the Brazilian Central Bank, they got a lot of things right. First, they required all banks to participate and included fintechs, too. Today, the majority of the participants are not Central Bank regulated. The rails were built by Red Hat and they offered support to banks on both the back- and front-end of the build. Its service is free for P2P and some B2B. Banks and fintechs were handheld by the Central Bank and by the time Pix was launched, the average Brazilian knew what it was.

Both UPI and Pix benefited from lower card penetration compared to the US and populations used to managing their financial lives on phones, more so than desktop or bank branches. The adoption has revolutionized how consumers and businesses move and receive money, however, it has also tanked payments fees for banks and fintechs. Revenue models have shifted from payments fees to enabling software. More on this in Part III.

Other countries have had mixed success and may foreshadow the fate of FedNow. In Mexico, where cash still dominates transactions, adoption of CoDi since launching in 2019 has been underwhelming. What went wrong? First, only banks are allowed direct access. This is particularly painful in a market with complex bank-fintech partnerships (Zac Thomas wrote a great piece on this). Second, the Central Bank left the front-end open for banks to build – banks that were not thrilled about adopting the new rail. There was little investment made from banks and no standardization from the Central Bank. Ominous.

The UK has been a clearer success, but only after a slow start. Faster Payments (“FPS”) in the UK launched in 2008 (with a pretty messy rollout) and has steadily grown to over 1 billion payments processed in Q3 2022 or, nearly £850 billion in value.[5] The Central Bank did not require banks to participate but was open to fintechs to join starting in 2017 (unsurprising then that growth picked up in 2018-2019). FPS was expensive to use for businesses in the early days and companies willing to pay were those that really wanted to delight their customers. But as time went on and options to access the rails multiplied, costs went down, and now anyone looking to send funds might as well use FPS, slowly making BACS (like ACH) obsolete.

So, how to connect?

There are many moving parts for FedNow to get to launch. As the Fed Vice Chair Lael Brainard noted in August 2022, “Ultimately the number of American businesses and households that are able to access instant payments will depend on financial services providers making the necessary investments to upgrade our payments infrastructure.”[6] Let’s talk about what those upgrades are.

For both FedNow and RTP, hardware is required for bank connectivity. As in, a physical thing (think Cisco routers) needs to be present and installed at the bank. Eventually this could move to the cloud but today, no. This is similar to Faster Payments in the UK and unlike UPI and Pix, which offered APIs and SDKs from day one.

To connect to RTP, as a bank or fintech it takes ~6 months (happy path) to 18+ months (less happy path - apparently what it took Chase) to onboard either directly (banks only) or through a partner (banks or fintechs). This could be similar for FedNow. Connecting directly as a bank (Chase or fintech partner banks like Cross River Bank and Column) requires application development, rigid SLAs, 2 data centers, TCH routers, designation agreement (aka bank is always responsible for originating transactions), and more. Connecting through a partner as a bank requires working with a “third party service provider” such as a core provider (FIS, Fiserv, Jack Henry) or a hosted gateway (Tabapay, Dwolla).

Anecdotally, talking to some vendors that used their cores (FIS or Fiserv) to connect, it took them 18 months and over $1 million. Jack Henry touts its ability to connect banks to RTP with its JHA PayCenter product, claiming it has onboarded the majority of FIs on RTP.[7] Fintechs can connect through their banks’ APIs or through partners (again, Tabapay, Dwolla, Orum, Alacriti).

As mentioned in Part I, only 20-25 banks are able to originate and those that can could have bottle necks from so much demand. Hey, CRB. Migration to ISO20022 standards also takes time. A typical migration timeline can run anywhere from nine to twelve months, depending on the partner and solution.

Beyond the technical process, the Fed has called out the inherent challenge that they are leaving the banks to fend for themselves in adoption of FedNow. “The time is now for all key stakeholders—financial institutions, core service providers, software companies, and application developers—to devote the resources necessary to support instant payments. This means upgrading back-office processes, evaluating accounting procedures to accommodate a seven-business-day week, arranging liquidity providers, deploying a new customer-facing application, and promoting instant payments for key use cases to customers.”[6:1] That is fundamentally a lot for a bank to take on, regardless of incentives.

What are those incentives? I will dive into those in Part III coming next week. Part III Unblocking and Unlocking will explore what needs to be true for real-time payment adoption in the US and some exciting ideas made possible from it. See you then!

Reply

Avatar

or to participate

KEEP READING