Comment by HoyaSaxa

That's really interesting. I worked in PCI (payment cards industry) and we had terminals we could relay the ISO8583 messages through, eventually opting to emulate via software for obvious reasons.

Always so cool to hear about this sort of stuff.

What is normal though? From the perspective of a hardware engineer, from the perspective of a contractor or small company developer, from the perspective of a developer at a medium-sized firm, and from the perspective of an engineer at a FAANG, what is normal is different. Twitter famously doesn't have a dev environment and that's not a bad thing. That's because coordinating umpteen teams to have an actually useful dev-dev and qa-dev env costs more than it's worth, in their eyes. And then, what does normal look like depends on when, too. Local dev envs looked a lot different before Docker came on the scene.

So back to the question, what's the dev env look like? :)

> And your employer is paranoid and keeps you in a digital prison for security

That, um, sounds reasonable to me in the context of what they're developing.

I'd rather not have "off-road improvisational innovation" with the nation's banking infrastructure, thanks. If that's what you want to do go write another JS framework or static site generator, don't work at a bank.

> So presumably they are interested in offering consumers the ability to pay for Netflix using FedNow instead of a credit card.

I do wonder how stuff like this will shake out. I will use a credit card, always, with any vendor that doesn't pass along credit card fees to the customer in some way. (Why would I choose otherwise? The credit card gives me rewards, and better fraud protection.)

But more and more, I see companies charging "convenience fees" for credit card usage or offering "discounts" for cash/debit. Hell, T-Mobile just started requiring you not use a credit card to get their $5/mo autopay discount.

So this is all cool (and perhaps would make it easier for people who don't have a credit card to pay for Netflix), but I don't see why I'd use anything but a credit card to pay for my Netflix subscription, unless they offer discounts for using FedNow. Which... they probably won't?

Have you looked at other systems across the world for inspiration / design choices, and if so, could you elaborate on how this system compares? For example, the use case mentioned is probably the prime use case for UPI in India, which has now been extended to become a full fledged payment network alongside CC networks etc.

> they'll probably be able to find a bank willing to charge them < $0.25

I guess that includes some very small values, but the upper bound seems ridiculously high.

I hope they extend that to actual invoicing standard, i.e. pass the invoice details in that RFP message, like something similar to https://www.finanssiala.fi/en/topics/finvoice-standard/

> I'm on the Request for Payment (RFP) Work Group that is composed of a number of financial institutions, service providers, and billers.

I'm just randomly curious: do you know which Federal Reserve Bank FedNow was developed at?

Why should they not be able to find a bank that charges <$0.05?

Other than with credit cards, there are no costs for customer kickbacks and chargebacks.

That sounds odd.

I can't imagine netflix giving up the stickiness of automatic recurring billing to say <2% of the transaction cost.

That sounds great!

No, Wire Transfers have been the official fast settlement method in US for a while. They have a fixed fee associated but given the larger transaction amounts that people generally use it for, it's not a bad thing. Everyday consumers have their silly apps for money transfer (PayPal, Cash app, iMessage Cash). Other than that, people are just used to transactions taking 2-3 days and over drafting because they made another payment and forgot about it. Yay, ACH!

I can think of 0 occasions where I’ve given anyone my bank account info who isn’t a commercial organization (employer, electric company, etc).

I had no idea it was the opposite in the UK.

Edit: with the exception of writing physical checks, of course. I use those when the receiver doesn’t accept Venmo or Apple Pay.

> Is this the first US implementation of "Faster Payments"?

No, there's already Zelle, which is fairly popular now, though not as ubiquitous as instant bank transfers in other countries: https://en.wikipedia.org/wiki/Zelle_(payment_service)

The UK and Ireland have identical banking codes (six-digit sort code & eight-digit account number) and constructed IBANs the same way (BIC, sort code, account number), but Ireland switched to using IBANs domestically, while the UK didn't. That means that you in the UK need one interface for domestic payments and a different interface for SEPA payments, while we use the same for both.

Wire transfers exist, but have a high fixed-transfer cost ($20 is not unusual).

The larger banks have their own systems that only work within the bank; some smaller banks offer systems that work with any bank that offers the same system.

ACH exists, and I've used it to move money between accounts I own, but there is some friction to set up. I don't know anyone who uses it for C2C payments.

This got me surprised too. In Mexico we are also used to giving our bank account CLABE number (https://en.wikipedia.org/wiki/CLABE) that is used to transfer without fees and instantly. Even small shops use it to get paid, friends to split dinner, etc.

Poland has BLIK, which links your bank account number to your phone number. Then, just send a transfer to the phone number instead of punching in the 26 digits of the account number. And if you don't want to share your phone number, you can use a temporary six digit code instead.

The US already has Zelle which does this. However the roll out was botched, many banks don't seem to use it and most people (including me until a few months ago) thought it was a paypal competitor - but it's actually a government based system system which renders free transfers between bank accounts (your own or others) with a cap of 3 or 5k/month.

The interface is very weird. Many people can't figure out how to use it. I ended up having to set up new email addresses and assign them to different bank accounts in order to distinguish my accounts.

Except Interac is controlled by the big banks, for the big banks. To the best of my knowledge.

No, US bank to bank transfers/payments are quite slow, and not commonly used for small transactions. But there are a couple substitutes that are used:

* Zelle is basically better bank transfers and is already supported by many (most?) US banks: https://en.wikipedia.org/wiki/Zelle_(payment_service)

* Random 'third party' money transfer services like Venmo, Cashapp, Paypal, etc.

But similar to messaging in the US, the main issue is fragmentation. There's isn't quite a national consensus like some other countries have.

There are three methods to do so:

1) Write a physical check (2-10 days from deposit, usually 2) 2) Use ACH (a virtual check) (2-10 days, usually 2) 3) Fedwire which costs $10-$15 to both the sender and receiver (15 minutes).

Why would any of it be under an NDA?

> The FedNow Service requires all messages to be cryptographically signed. The service validates the signature and association between the entity sending the message and the key used to sign it.

Hey, that's neat. I'm super curious how much the internals of this thing could be compared with something like a cryptocurrency. Are those signatures representative of the identities making the transaction? Might it be technically feasible some day for me to craft a transaction on my phone to send money to someone, then publish it directly, and have the person instantly confirm that they received a payment without needing to talk to a bank?

I'm really curious if this is what is going to eventually morph into the CBDC that everyone seems so excited about, or if that project is going to start from scratch.

I'm no expert on this so this is pure speculation, but what immediately jumps out from this document is the amount of security- and availability-critical work that depends on each member bank. With wire transfers this has historically been achieved by gating transfers behind physically visiting a branch (not universally true). The synchronous nature (recipient must confirm transaction in real-time) of transfers may also cause annoying failures when recipient banks do maintenance or something at inconvenient times.

Hmm, surely there's some kind of support for a pull request that has to be approved, no?

It seems like requiring the consumer to manually set up a push payment to a company would probably be annoying and error prone, compared to having them entering their details on a website and then the company requesting payment.

We already have a push system called Check 21. You scan an image of a check and it will send the money instantly to the bank instead of through the Fed. It created after 9/11, as money couldn't move when the Fed was frozen.

American Innovation™.

U.S. banking is so far behind the rest of the world. This development is very much welcome.

IBM MQ has been the standard for message queues for literal decades.

Hitching a horse to a different technology platform that has only been around for a few years to complete a project that should last for many more decades would be an architectural choice that would only lead to high costs and high risk of major changes in the future and puts the whole system at risk.

More likely, everyone in charge of this project on the government side is over 55 and still think of IBM as a signal of quality and reliability.

I spent a couple years deploying and integrating IBM MQ, and I own a couple of services currently that interact with it. It was (just a couple years ago) and probably still is more robust than current open source solutions, as long as you weren't planning on forking the code for some very specific use case that requires heavy modification, or the more likely situation of just wanting to save money.

As far as message queues go for something like the federal reserve, IBM MQ is really the only option that wouldn't raise a lot of eyebrows in the industry. The Fed is not the kind of institution that I think people would be lenient on for being open and innovative with their software solutions, banks really need to know that this thing is going to work and they all run IBM MQ themselves already. Not to mention the integration possibilities with Db2 and IMS, which are both huge in finance.

My only complaint is that it is very expensive. That's the story with most of the kind of hardcore technical products IBM sells that are likely to wind up near mainframes. I'd imagine the Fed gets a sizeable discount though.

Let’s be entirely honest, it would be unreasonable to assume they aren’t going to log every bit of data they can.

I don’t know why anyone would assume they aren’t going to link it with the IRS, and make it available to any agency that asks.

If the plan is to offer a “money request” service and offer much the same functionality as Venmo, there will be a “for” line.

Even with credit card payments now, they are coded at a minimum.

Everything is logged always.

The question I guess still stands WRT...if FedNow is so easy/great/instant, is there even still a business model for Plaid?

This was super helpful, I have always wondered how this all worked

Couldn't having payments settle so quickly result in increased risk of overall system instability? I don't have a specific example, but I'm thinking of things like bank run panics. I'm sure this sort of thing would have been considered, however.

Famously: http://web.mit.edu/jemorris/humor/500-miles

So if you're both in NYC it should be fine. At the very least T + ping time + 1 ms

And this should be available to customer investors (dudes at home) before retail investors (hedge funds)

Apologies if I’ve misunderstood you (edit: I have) but assuming you are saying that 1ms to transfer funds between banks is ridiculously slow, why do you say that?

Light travels about 300km in one millisecond in a vacuum, about 200km in optical fiber. The best achievable theoretical fiber optic RTT for NYC-LA is about 35-40ms. In practice 65ms+ is more realistic due to routing overhead and the fact that cables aren’t always laid in a great circle. This being a financial API with three parties involved in most transactions (the two banks and the fed clearinghouse) there is sure to be more than one round trip involved for TLS establishment, authentication, verification of funds and account availability etc, many of which involve traversing many inevitably complicated systems on each side. It would shock me if such a system could realistically target anything less than 500ms P50.

Some transactions can be rolled back asynchronously.

There are physical bank note, database from different system in trust or untrusted parties that need to be cross checked and reconsolidated

BigQuery is ACID compliant and easily handles petabytes.

https://cloud.google.com/bigquery/docs/introduction

Generally speaking, you won't find financial institutions using Postgres for core line of business databases.

Any database easily handles terabytes, idk why that's a condition.

DuckDB and SQLite easily handle terabytes of data. They're just not so much for cloud based apps, or things that need multiusers and access control junk. They're the best choice for just about everything else though.