logotype

Thanks for the suggestion! At this stage, debt is not a feasible option for us. Our focus is on scaling the business quickly and VC funding is the preferable route to achieve that. Having the runway and support from investors will allow us to fully dedicate ourselves to growth and execute our vision effectively. Re value prop - true. While the existing clients are using FIXParser as a plain old library I was thinking where the puck is going to be, it's going to be all MCP with A2A frameworks so i pivoted and most of the focus was on building the MCP features. We have received interest from VERY prominent firms in finance thanks to our focus on MCP FIX features. I doubt that a sr engineer can put that together in a few days.

We’re a startup enabling AI agents speaking to the market. Removing the need for complicated trading UIs.

Thank you, I haven’t thought of this. Will look into it!

Thank you, this is very helpful! Will keep this points in mind. Regarding exit, yes that is certainly one outcome. But it’s not something that we have mentioned in any of the pitch materials. Regarding shares I’ve followed the YC standard.

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

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?

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

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.

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

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

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.

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.

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 :)

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!

how about you, working in the finance space too?

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.

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

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 wish! I got zero from that trillion dollar trade, but just knowing about it is exciting. Such is life :)

yeah that's it :)

:) it's all part of the game

you guys like sunglasses

best of luck!

100%

The “marketing” aspect of a job posting is bad because it’s not genuine. And a large proportion of applicants are using automated tools which is adding to the problem. The people who are actually looking for a matching role and who actually write their application themselves are simply lost in the noise.

interesting! I haven’t heard about this, thanks for sharing.

Exactly! The system is flawed right now because it’s automated on both sides, for often the wrong reasons

exactly, it is the same. basically the simplest way to parse is to split the message into key/value pairs separated by \x01 (SOH), and then inflate/enrich the message with field names and enumerations to make the message more understandable. the protocol is deceptively simple and the complexity moved to the validation instead, here's where the specification + versioning + vendor specific fields become complex because the devil is definitively in the details

xml/xsd is preferred as the schema definition, but the format "on the wire" is mostly tagvalue ASCII over TCP sockets these days (or binary using SBE if its latency sensitive e.g. HFT). JSON is relatively new in the FIX world. Some applications could encode fix in the front-end/browser and I can see some advantages of using FIX JSON in those scenarios and that's why we added support for it in FIXParser https://fixparser.dev

hehe! spoiler alert: they haven't