Comment by dheera
3 years ago
Does this end the T + 2day ridiculousness? It should be T + 1millisecond at worst. What does it take to update 2 "balance" values in databases?
3 years ago
Does this end the T + 2day ridiculousness? It should be T + 1millisecond at worst. What does it take to update 2 "balance" values in databases?
> What does it take to update 2 "balance" values in databases?
Quite a bit more than you seem to think.
https://engineering.gusto.com/how-ach-works-a-developer-pers...
This was super helpful, I have always wondered how this all worked
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.
You must remember, the US is very late to the "instant" payment party. This isn't a groundbreaking development.
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.
Good question. Did that happen in any other country with faster payments? And SVB collapsed fast before this.
5 replies →
T + 1 millisecond seems impossible. Light can only travel a couple of hundred miles in a millisecond.
Famously: http://web.mit.edu/jemorris/humor/500-miles
Expected the sendmail story, got the sendmail story.
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)
"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
5 replies →
The PDF linked in the thread [1] specifies T+20s or no settlement.
[1]: https://explore.fednow.org/resources/technical-overview-guid...
T + 2day is ridiculous. T + 1ms is also ridiculous (speed of light and all.)
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.
I believe the comment you replied to was suggesting that 1ms is infeasibly fast.
1 reply →
This is the most hacker news conversation ever.
2 replies →
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
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.
BigQuery is ACID compliant and easily handles petabytes.
https://cloud.google.com/bigquery/docs/introduction
Nobody in their right mind is using BQ for oltp workloads
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.
1 reply →
Generally speaking, you won't find financial institutions using Postgres for core line of business databases.
What will they be using? A similar SQL database that has a big vendor behind it like Oracle, or something else?
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.