Ask HN: My software has moved trillions of dollars. AMA | Hacker News Reader

Ask HN: My software has moved trillions of dollars. AMA

6 pointslogotype27 comments

It's a software library that facilitates trades between counterparties, a.k.a. the Financial Information eXchange protocol. My journey from building a hardware accelerated HFT system to pivoting to high-level Typescript. Ask me anything if you're curious.

View on HN

Before it all started, back in the early 2010s, I read about High Frequency Trading, and it sounded super interesting. I wanted to understand how it worked. Without knowing anything about it, I thought I could simply get a Xilinx dev board and start using Verilog to build a hardware appliance for fast trades. Little did I know that a cheap dev board with limited logic gates wasn’t even enough to fit an Ethernet IP, let alone the challenges of using Verilog. I soon realized that it's probably more suited for electrical engineers (EEs) than software engineers (SWEs).

After that experience, I started rebuilding it using Go, Dart, and other languages. Then TypeScript came along, and eventually, it was rewritten in TS. Traditionally, FIX is written in lower-level languages, but there’s definitely an advantage to using TS, as it allows us to generate FIX messages directly in the browser.

Another interesting thing that got me excited about HFT is the microwave networks that connect exchanges in the US. It's not often you can say "because fiber optic is too slow," but for these use cases, it's actually a technical advantage. Every piece of the stack is hyper-optimized!

Wouldn’t it be more accurate to say, lower latency?

Because surely fibre optics beats microwave on speed?

You're right. It's all about latency not throughput!

I have written a lot of C code running on Unix supercomputers for fund managers.

Based on my perhaps limited experience, I would have never thought that any VM based language would be accepted for production use. Could you explain how and where your software is being used in the banking world.

I used to work at the big investment banks for a long time. Around 2015 they began transitioning their native apps to web apps (mostly for high-touch trading), so VM based languages are very much used for initiating trades to various degrees, of course in the majority of the cases the actual FIX message gets created in some back-end running C++ or Java.

But there are exceptions, FIXParser was used to create the actual, real, over-the-wire FIX message to trade a trillion dollars in a couple of minutes by a large financial institution. And this is just one example I heard directly from the people involved. The library does not have any metrics/analytics so I can't actually know how much it's been used in the industry.

Would love to hear more, what was the C code used for, specifically? What information did it process and how? In real-time or batched?

Very real-time, as in Unix with real-time kernel extensions. Direct dedicated line to the exchange floor, processing trading info to recalculate portfolio positions and extrapolate potential future movements. Traders used this info on one screen and then input their trades on their dedicated terminals.

Very cool! Is there any metrics you could share at a high level? e.g. what latency (sw/hw)? throughput? what type of protocols/connections was used? what level of concurrency/parallelism? anything else? Cheers

I wasn't expecting TS and HFT in the same sentence. Are you pivoting to something else with TS? Surely it's not for HFT?

It began as an exploration into learning about HFT, but later shifted to TS. As far as we know, our clients do not use it for HFT. While we still prioritize performance, we are capable of processing a million trades per second on a single core. This will drastically improve in the near future though :)

I see, yeah if you need performance then TS is probably not a good choice, but I'm not familiar enough with HFT to know if that's always needed. Maybe that's only in certain subdomains. I've just seen some talks on optimizing HFT with C++, and it sounds like nanosecond performance is the target.

TS/JS is surprisingly fast these days. FIXParser has been performing at 1-2 microseconds per FIX message for several years. And that's with basic performance optimizations while keeping readable code. With further optimizations using WASM we can reach nanosecond speeds...

your comments on the Frontend Treadmill makes sense. It's sad how FE development has become. I used to build front-end apps without frameworks, super fast and efficient. No need to constantly update dependencies. These days people would laugh at you for not using libraries and frameworks to glue a house of cards together.

Yes the FE is a huge mess for large interactive client apps. I think WASM might be a good alternative with bad SEO as the downside.

... can you say more than the absolute bare minimum you have so far? It's impossible to come up with any decent questions without knowing anything.

edit: wait, is this it? https://fixparser.dev/what-is-fix

how about you, working in the finance space too?

yeah that's it :)

So, uh, can you say more about it?

FIX is a simple protocol, typically consisting of key-value pairs in its most common form. However, that's not the entire picture. The protocol involves a lot of complex logic, including validations and rules. Although it was developed in the 1990s, it remains widely used today.

Basically, the process involves connecting and handshaking through a series of messages, which results in an active FIX session. Once the session is established, you can send bidirectional messages, such as requesting a market data snapshot to receive prices, submitting a new order, or anything in between.

Can I have some?

I wish! I got zero from that trillion dollar trade, but just knowing about it is exciting. Such is life :)

It makes me wonder how other open-source developers feel when their products are used by big corporations that pay nothing for them but generate tons of cash.

I'd like to understand how an open-source developer could acquire sufficient domain knowledge and expertise to write production quality code without actually working for one of the banks or their vendor organizations. Then any such work would probably be covered by NDAs, etc.

It wasn't easy. When my imaginary friends was out partying I was sitting there, home alone, reading FIX specs

You admit: "I used to work at the big investment banks for a long time." in an above reply.

Which is exactly my point. You need extensive domain expertise and reading then implementing FIX specs. That is most definitely not a characteristic of "open source" endeavors.

Reply on news.ycombinator.com