undefined | Better HN

0 pointsccleve2y ago0 comments

Tell us as much as you can about the tech stack. What is going to be able to handle truly massive volumes of transactions? Database, hardware, communications channels, programming lang, everything.

0 comments

HoyaSaxa2y ago

Not trying to side-step the question, but The FedNow Service Technical Overview and Planning Guide[1] goes into depth on what is not under NDA.

[1] https://explore.fednow.org/resources/technical-overview-guid...

CobrastanJorji2y ago

Why would any of it be under an NDA?

ke88y2y ago

At the very least, one would hope that credentials and perhaps also certain design documents such as threat models aren't public.

There may also be implementation details or code which are subject to NDA, either from the Fed itself or from service providers such as IBM in this case. Sometimes you can get that info from a FOIA request, but that doesn't negate the fact that the employees working on the system are bound by an NDA. The FOIA has to happen and run its course.

4 more replies

mfer2y ago

Security is one good reason.

Fraud and people trying to mess with the system has been a long term problem and likely always will be. The results of which can hurt people. Keeping details private can make it more difficult for those folks.

If we try to prioritize goals of a system like this... security for people should be one of the highest. I think of the middle income single parent when I envision an example of a person in this system.

px432y ago

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

ericpauley2y ago

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.

1 more reply

j / k navigate · click thread line to collapse