Based on reading through the PDF, I would summarize FedNow as a service which provides the low-level infrastructure to support near real-time money transfers be

Based on reading through the PDF, I would summarize FedNow as a service which provides the low-level infrastructure to support near real-time money transfers between domestic US bank accounts. The system is implemented as a credit-only system - meaning payment transactions must always be initialized by the sender. The protocol is a full handshake between the banks which provides the ability for the receiving entity to confirm the account number of the destination account in real-time and provide confirmation to the sender that the transfer is accepted. This is notably different from ACH where errors can come hours or even days after the fact. Account identifiers appear to be standard bank account and routing numbers as they exist today -- I say this only because I couldn't find anything in the PDF saying otherwise. There is a section on using "Alias-based Payments" and on how directory services might be integrated or even centralized, but the current approach would rely on 3rd party directory services to facility "alias-based payments" (think Venmo). IMO a major security shortcoming of FedNow is that it reuses the existing account numbers. As a credit-only system, if a new (unique) account identifier was used then that number could be shared freely, printed on invoices or web pages, and handed out without any loss of safety, and used without the need for a directory service. Aliasing could be built on top this new unique number in 3rd party directories, but it would no longer be a security method, rather purely a usability one. The service will use ISO 20022 messaging standard (https://www.iso20022.org/ https://www.iso20022.org/) and will define both payment and non-payment message types which include the ability to attach meta-data such as invoice and receipt information, as well as to transmit a 'Request for Payment' to make up for the lack of debit transactions which would normally be used for recurring payments. In the 'Request for Payment' use-case, the account holder would be presented with a user interface provided by their banking institution, e.g. in their bank's mobile app) which would list pending requests for payment and provide the ability to approve payments. From what I can tell, there's nothing necessarily stopping a bank from providing a UI which could allow pre-approving future payment requests, e.g. by matching the date / amount / account number of the Payee, but if the 'Request for Payment' doesn't include the necessary meta-data it becomes increasingly difficult to not require the Payor to manually approve recurring requests. For the use-case of bill payments, I can only hope that the messaging format could be standardized to the point where something like the following could be possible; 1) Checking out at a retail store. The register computes the total amount due. 2) Select FedNow in our Apple Pay / Android Pay settings as the payment method and wave your device in front of the payment terminal. Here's where you would want NFC to be able to transfer a one-time-use secure identifier for where the payment request should be sent. 3) Phone presents a confirmation screen with the name of the store, total amount, and an Approve button. The one-time identifier sent in Step 2 could carry an implicit approval up to a certain amount (e.g. $250) 4) Full itemized receipt from the transaction is attached and automatically saved in the wallet. 5) Total amount charged is reduced by 1% as a bonus for not using a credit card. The key component of the system is a service which hides the long-standing / re-usable account identifiers from the POS system, and replaces it with a one-time use only identifier. At first glance it seems like such a system could conceivably be hacked on top of FedNow by a type of directory service that also acted as a proxy for the Payment Request messages.