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?

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.

T + 1 millisecond seems impossible. Light can only travel a couple of hundred miles in a millisecond.

  • 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 →

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.

  • 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.