TLDR: Nearly all payments will irrefutably settle within a handful of seconds
Strictly speaking the primary means in which money moves in the United States from a volume perspective is ACH today. That system is a T+1 day from a default perspective, but it has offered the option to same-day settle during a handful of batches throughout a business day. However, ACH is not irrefutable and so it is common to have holds associated with this movement of money.
FedNow is truly 24/7/365 and push only.
All payment flows are subject to an end-to-end payment timeout clock of 20 seconds, starting from the creation timestamp to the point at which the recipient FI (almost always really a Service Provider on their behalf) sends a formal response that they intend to accept or reject the message.
An accepted payment must then be posted to the receiving account "as soon as practicable, but no longer than a few seconds” unless there are compliance/fraud concerns.
In practice, it should rarely take 23 seconds and will likely take 1-5 seconds from an end-to-end perspective depending on the processing speed of the originator, receiver and FedNow Service itself.
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.
Yes, it absolutely does increase the overall system instability. However, that is at great benefit to the consumer. There are some safeguards in place in the actual FedNow Service, but it is primarily up to the Service Providers to give the financial institutions tools to manage risk. This includes features like liquidity management, circuit breakers, fraud/compliance monitoring, limits, etc.
Faster settlement can also have stabilizing effects. With less money in transit there's less counter-party risk. Annoying rules like having to wait 10 bank days to spend money from a larger check you deposited can go away. The whole point of a checking account is liquidity.
I'm not sure if that's what the previous poster was referring to, but before SVB officially collapsed it tried to get an emergency loan but failed because the system for such emergency loans is slower than the systems its clients could use to transfer money out.
> And yet! Man! What the heck! A lot has been written about how SVB was a bank run for a speedier, modern age. Instead of hearing a rumor at the coffee shop and running down to the bank branch to wait on line to withdraw your money, now you can hear a rumor on Twitter or the group chat and use an app to withdraw money instantly. A tech-friendly bank with a highly digitally connected set of depositors can lose 25% of its deposits in hours, which did not seem conceivable in previous eras of bank runs.
But the other part of the problem is that, while depositors can panic faster and banks can give them their money faster, the lender-of-last-resort system on which all of this relies is still stuck in a slower, more leisurely era. “When the user interface improves faster than the core system, it means customers can act faster than the bank can react,” wrote Byrne Hobart. You can panic in an instant and withdraw your money with an app, but the bank can’t get more money without a series of phone calls and test trades that can only happen during regular business hours. And so sometimes a bank that theoretically has a lot of liquidity can just run out of cash.
"retail investors" normally refers to individuals at home and T+2 doesn't affect them because they have margin accounts.
The only limitation is that if you day trade, you'll need $25k in your margin account. If you don't day trade or you have $25k, you can withdraw $0.01 a few milliseconds after selling $0.01 in shares
You can use that, but there are pretty well understood terms in finance already (like retail investors), and probably best to use the standard if you want to be well understood.
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.
Not sure it's even useful to call it a "transaction" at that point, since nothing has been transacted. It feels like the difference between updating a value in-memory and committing a value to the database. Maybe you can hide the latency, but that hasn't removed the need to actually do the transaction, eventually, and now you have the added problem of managing consistency.
The problem is, which "database"? If you know the data is always going to be in the range of ~1TB, use Postgres or some other ACID database. But I don't know of any petabyte scale ACID compliant database.
Also I'm not sure if ACID is sufficient or not for banking systems.
Yes, but in addition to being ACID compliant (serializable ANSI), you need to support a million transactions per second - it’s not just about data size.
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.
Quite a bit more than you seem to think.
https://engineering.gusto.com/how-ach-works-a-developer-pers...