Weekly Updates

FedNow was launched in the US. It is their real-time payments (RTP) rail which Fed hopes will modernize US’ current payment infrastructure. Like other RTPs, FedNow works 24/7/365 and completes transactions in 20 seconds or less. If it turns out to be a success, such as Pix in Brazil, it could bring many improvements for US citizens and companies.

While we are rooting for FedNow to succeed because of the social impacts government-led RTPs can have on society, we believe that some of its characteristics make it hard for FedNow to achieve critical mass and strong network effects.

We'll dive into FedNow's main characteristics below. Most of our analysis is based on Fed's Operating Circular #8, which defines how FedNow works. There is also a nice video showcasing how it works.

Clearing House

The Clearing House is centralized and controlled by Fed. The settlement is done in real time (Real Time Gross Settlement - RTGS) on the participants’ accounts. The great advantage of this kind of architecture is that it enables each participant to establish a 1-to-n connection by integrating solely with one entity (the Clearing House). If all participants are connected to the Clearing House, they only need to worry about one integration to be always two hops away from any other participant.

Liquidity on the participants’ accounts can only be managed during specific time windows (Fedwire Funds Service's operating hours) and at USD 10 million per day. The daily limit is relatively small for an RTP, but it makes sense since its operation has just started. As to the limitation to a time box, it is fine and shouldn't affect the 24/7/365 nature of the rail. Pix has a similar restriction, and the only impact is that institutions need to employ a little bit of planning into the liquidity of the account connected to the Clearing House.

One difference, though, is that Fed will not block transactions based on lack of liquidity but will apply intra-day and overnight overdraft fees, whereas, in the Pix rail, the Brazilian Central Bank (BCB) chose to create a specific credit line banks must actively deploy on a specific operations window. More recently, BCB also changed pay yields on the funds left on the participants’ liquidity accounts to incentivize them to keep these accounts well funded. From the FedNow Readiness Guide:

Participants should not expect the FedNow Service, at initial launch, to reject payments based on a participant’s insufficient balance or overdraft capacity, even if the Federal Reserve Banks do so for other services. However, standard intra-day and overnight overdraft fees will apply.

The rail also has a maximum value that can be transferred in a single transaction: half a million USD. This should cover most, if not all, of the relevant use cases.

Participation structure

At this point, participation is voluntary, and adoption has been small. Only 16 of the more than 4000 banks have joined the rail. This is a big difference from Pix, where 34 regulated institutions with over 500 thousand accounts (🇧🇷) were required to participate. Other 728 regulated institutions voluntarily adhered (🇧🇷) to the launch, in part because the rail would connect at least 90% of the accounts in Brazil (🇧🇷) from the first day of operation.

The lack of mandatory participation makes it substantially harder for FedNow to acquire critical mass in terms of network effects, which is decisive for the success of the rail.

The structure of participation is similar to what was done in Brazil as well. Participants can connect directly to the clearing house (holders of a Master account) or indirectly through a Correspondent, which holds a Master account and provides settlement accounts to these indirect participants.

The connection to the clearing house does not mean the institution needs to build an internal service to manage all the requirements to participate in FedNow. Institutions can hire non-regulated service providers that do the heavy lifting of connecting with the rail. This is instrumental in facilitating adoption by smaller regulated institutions and ensuring better grounds for competition.

One place where FedNow will likely face issues in the near future is regarding availability. Institutions can have 24h per quarter of planned downtime (close to 1% of the operating time), and there is no clear expectation of what is acceptable regarding availability. While it is important to be lenient with availability in the launch of a new rail, it is fundamental to clearly communicate expectations on availability substantially before the launch because this information substantially influences architectural decisions. An architecture designed for 99.9% of uptime can completely differ from one designed to support 99% of uptime. Changing from one to the other has substantial costs for the company developing them.

99% uptime is not reasonable for critical infrastructures.

Architecture

The FedNow architecture, while similar to Pix's in terms of message flow, has chosen different technologies. While ISO 20022 was also used, the messages are exchanged through a message queue instead of the protocol HTTP in Pix. In Brazil, HTTP was quite important to facilitate adoption from smaller banks because it is a widely known protocol and reduced the implementation cost.

FedNow adopts one of the best practices when working with queues: having a dead-letter queue. Unfortunately, the documentation does not mention how many dead-letter this queue can hold and what will happen in case dead-letters cannot be produced. Since error codes are classified as confidential, it is also impossible to infer the behavior from possible error messages.

The last point about architecture we want to address is the payment consistency model. We could not find explicit information on consistency, but the requirements for an eventually consistent model are present. For this type of critical service, an eventually consistent model is adequate and is the one adopted by Pix as well. While the requirements are there, at least one of the idempotency validations for an eventually consistent system is not, which makes it easier for less experienced developers to miss consistency bugs in such critical infrastructure.

This specific validation should happen when the payee institution receives the confirmation of the final state of the transaction (a pacs.002 ISO 20022 message). According to the documentation, this message is to be checked against a previous transaction message (a pacs.008 ISO 20022 message). Still, a pacs.002 message must be consumed in an idempotent way, so additional validation is necessary to ensure that only one pacs.002 was consumed for each pacs.008 to avoid processing the same transaction confirmation multiple times.

If this bug happens, it could credit the transaction amount multiple times on the destination account.

Security and Fraud Prevention

Again, most about security and fraud prevention is classified as confidential, so it is impossible to analyze the security and fraud prevention capabilities directly. Most of what we can do is infer based on what is written.

As expected, the messages exchanged between the clearing house, and participants are signed. Considering NIST standards should be applicable in this case, we expect the signature scheme to be robust. But we could not review any information regarding connection security apart from the fact that direct participants need to connect through specific networks. There is no specific information on whether strong forms of authentication, such as client certificates, should be used.

Fraud prevention seems to be in a worse position. While participants should report fraud cases, the details of how this happens are confidential. What exists is a participant denylist where the payee institution can add accounts to have transactions blocked directly on the clearing house. This only affects transactions that involve that specific participant and is not a rail-wide block.

The effectiveness of this denylist is close to none because the participants could simply decline the transaction instead of registering it on the clearing house. So the additional mechanism does not add any security layer, and it's unclear whether institutions will go through the trouble of blocking the transaction in the Clearing House or simply deny transactions on their side.

To understand how important that is, Pix's DICT also stores multiple signals reported and consumed by all participants in the rail in each transaction. These signals can be consumed and added to sophisticated prevention models, which can decline transactions. And anyone can see all the documentation for this (🇧🇷) and validate externally, which substantially enhances the security of the rail.

One last point about fraud prevention. Customer notification of transfers is not mandatory, only marked as a best practice. While from a business standpoint, it may be reasonable not to require it, for fraud-fighting, notifying the customers is fundamental. The earlier a fraud is reported, the safer the rail can be. And it is not like the US is much better than Brazil or Mexico in fraud prevention.

A new RTP on the block