Heh, I worked together with Richard for quite a few years. Yes he's done some great writing on the topic of how banking works and is very knowledgeable. I don't think he reads Hacker News much though. The reason there's not much info out there on how it works is that it's mind numbingly complicated. It's mostly open but the exact technical details vary by country. The gist is that every bank has a connection to the central bank's dedicated securities settlement computers. Connection here means either:

1. A fibre leased directly from a telco, that physically runs between the bank and the central bank via one or more switching centres. The point is that it's not the public internet. It's a private network and in some countries may not even run on TCP/IP but something older.

2. A connection via SWIFT.

3. A connection via the internet.

SWIFT is the most popular approach and it's common that internet access is less powerful than if you connect via SWIFT. For instance it'll have fewer features, lower SLAs and hilariously the ECB closes its internet access at night for "security reasons" (presumably they have people paid to physically watch internet traffic into the system). SWIFT is a private or semi-private network that you can't connect to unless you have either a direct hard line, or a business relationship with a connectivity broker, or maybe these days they also allow direct internet access via VPNs. It's basically a giant message queue broker with some business logic and data formats layered on top. SWIFT lets you send messages from one organization to another with authentication and being independent of details like underlying IP addresses. SWIFT will queue the messages for the organization if they aren't online right now, although mostly of course banks always are, and they do some validation and identity checking along the way (sometimes). You pay per message. Getting a SWIFT connection is part of what it takes to set up a bank.

So the central bank and the banks all have connections either to each other or SWIFT, and even if they're directly connected they're probably still using SWIFT format messages which are a sort of open standard or they'll be using something like a central bank specific XML format. If you really want to nerd out on the details try reading the TARGET2 user guide. TARGET2 is the ECB's central computer systems:

https://www.ecb.europa.eu/paym/target/target2/profuse/nov_20...

e.g. "The PM account holders may access the SSP via SWIFT (SWIFT-based PM account holder) or via Internet (Internet-based PM account holder). For the Internet-based access, special rules apply, as described in section 3.1.7 Internet-based access."

For securities trading (how CBs create money) check out the TIPS user guide which shows you how the UI works: https://www.ecb.europa.eu/paym/target/tips/profuse/shared/pd...

To connect to any of these systems whether via SWIFT or the internet you will need to be issued with certificates and the keys will need to be in HSMs. This is checked as part of the onboarding process. Banking runs off PKI and large banks can have entire teams devoted to nothing but managing X.509 PKIs.

The central bank runs a large computing system that does a variety of tasks. These are still usually mainframes. These computers track the balances of each bank with an account (rarely CBs will give accounts to non bank entities), allow transfers between them and so on. Actually it's more complicated than that - generally banks will build up debts between each other during the day which are tracked by the Real Time Gross Settlement system. At night the system closes for a few hours and the debts are netted out to detect cycles in the graph and delete them, reducing the amount of capital you actually need to hold with the CB. This is all done by proprietary CB software.

In older times it was normal that what you get from these quasi-government agencies is just a message based API, but these days they may also provide (incomplete?) GUIs. The ECB TIPS system for example provides a GUI for basic uses, which as recently as 2019 is/was based on Java applets and ran only on IE 11 as a consequence. I believe the Fed UI is still literally telnet to a mainframe. But most banks will develop their own software and UIs to interact with these systems. Traders are notorious power users and can benefit enormously from custom written software. Web apps are often a poor fit for them because the apps are trusted so the sandbox just gets in the way, they want to have a bazillion windows open on half a bazillion screens, they want full keyboardability, powerful analytics tools, Excel integration and so on. So another part of running a bank (that does trading at least) is the development of the necessary tools and software for your staff.

So in summary, to start a (big) bank you will need at least:

1. A SWIFT connection, possibly via a broker, which in turn means needing HSMs and maybe renting a dedicated (switched) fibre connection to your datacenter.

2. Accounts with the central bank. Getting these in turn implies security audits, capital requirements, licensing requirements, and so on. Getting a banking license triggers yet more tasks like proving to regulators you have developed or bought an anti-money laundering platform (these are very expensive).

3. A software stack that can drive the relevant APIs and messaging systems so you can actually move money around the financial system. In turn your customers need ways to drive their money so you need software for your users and agents that turn mouse clicks into the underlying XML/SWIFT/FIX messages.

I've erased a massive amount of detail here e.g. the role of CSDs in securities trading. The financial system is tremendously complicated, but at a technical level it's all held together with PKI, XML, SWIFT/FIX messages, dedicated connections and a LOT of Word documents.