Building Custom Solutions vs. Buy-and-Build Software

When your organisation sets out to launch a low-latency trading platform or upgrade an existing trading system, one of the first questions that arises is whether to commission fully custom trading software or to combine off-the-shelf components with internal code. That decision has far-reaching consequences for time-to-market, cost, risk management, customer support obligations, and the tech stack your team must maintain for years to come. In this article we recount a real-world experience that highlights the pros and cons of each route and shows why a strategic buy-and-build model often delivers the optimal balance for financial institutions that need deterministic speed and real time data processing without the burden of writing every single line of code.

The Challenges of Building a FIX Engine

The first day I was introduced to FIX was when I worked at an investment bank in London as a developer; I was told to write a feed handler to retrieve market data for an internal trading platform. Bear in mind that at this time, I knew nothing about FIX, apart from googling it for about 10 mins on the internet. With a touch of overconfidence and slight arrogance, I set to work coding a direct socket connection to the remote FIX endpoint—“how hard could it be?” That enthusiasm is common when teams embark on greenfield trading software development projects, but as you will see, complexity mounts quickly. Seasoned development companies know that the initial proof of concept is only a fraction of the work needed to deliver production-ready trading solutions.

So, What is FIX ?

Financial Information eXchange (FIX) is both a market data format and a protocol; it is used by investment banks to place orders and receive market data and has become a global language in financial trading. Because virtually every custom trading platform must integrate with at least one FIX venue, understanding the nuances of the protocol is vital to automated trading as well as discretionary execution desks. The format of a FIX message controls how it is encoded. All FIX messages start with 8=FIX, which denotes the start of a FIX message. They then go on to list key and value pairs; the keys are represented as numbers (known as TagNumbers) followed by a ‘=” delimiter to delimit the values. Each key=value combination is then delimited by the \u0001 character, which is sometimes visually represented as either ^ or | The value is often written in a semi-human-readable format. I say semi-human readable because most of the time it is human-readable, but all too often FIX will use a single character to denote a state or type of message; these characters are not always that obvious; I agree that the character ‘B’ for Buy and ‘S’ for Sell makes sense, but other characters are used that make no sense. For example, ‘D’ denotes a New Order Single message, which is a message that is often used when you wish to place an order with your counterparty. By the time you have mapped every tag to internal data structures, added unit tests, and implemented support for multiple FIX dialects, you have already invested a sizable portion of your software development services budget.

Image 1. An example FIX message in FIX format

When it comes to the FIX protocol, you have to be careful, as it turns out to be much more involved than just having the correct FIX message format and being able to decode the key=value pairs. The protocol also includes ensuring the counterparty has successfully logged in and that any missed messages are retransmitted; it also requires support for gap fills and sequence resets. For an in-house team, implementing that functionality means writing trading algorithms that recover seamlessly after a network blip and guarantee real time consistency of order and trade states—capabilities that customers simply expect from professional stock trading software.

Back again to the coding. The first challenge was to get past the login phase; it looked like this login message was mandatory! Over time, I managed to put together enough of a login message that the other end came back with a login reply, but it was not long before my colleagues started taunting me, “Why don’t you just use Quick/FIX4J?” Their suggestion underscored an industry truth: even highly capable development services teams frequently leverage existing open-source components to accelerate platform development and focus scarce engineering cycles on differentiated trading strategies rather than plumbing.

Saving face and trying not to show that I knew nothing about QuickFIX, I quietly down my I.D.E. and jumped back onto the web browser. While doing a bit of research about QuickFIX, I was thinking — “perhaps using this open-source library could be simpler than implementing it all myself”, or “maybe it’s going to take me longer to understand how to use this library.” That internal debate mirrors the broader build-versus-buy decision that every software development company working in financial services faces.

The library was extensive, and they clearly put a lot of work into it, but I was overwhelmed by how complicated it all looked — does it really need to be like this? Evaluating libraries, SDKs, and commercial platform development services can itself consume valuable sprint capacity, yet skipping such due diligence can expose your trading systems to latency spikes and unforeseen integration costs.

At the time, I was working alongside a team of developers that I looked up to; these guys stood by the “No code is the fastest code” mantra; everything they wrote was super optimal; they would work with raw byte buffers rather than create unwanted objects, and their Java code looked more like ‘C’ code than any Java I had ever seen before. That low-object-creation philosophy is invaluable when building custom trading platforms that must process real time market data in microseconds.

So, I got back to my PC and proceeded to implement the lightweight raw byte buffer parser route; over the next few weeks, I was starting to get end-to-end data going through the FIX adapter, and when I was finished, it screened. During that period I learnt first-hand how trading software development demands meticulous attention to technical analysis of GC pauses, CPU cache behaviour, and network jitter—areas that many generic software engineers rarely explore.

Now looking back on those early days, I ponder, “did I make the right decision?” and “should I have implemented it myself?”. The answer is I think yes, it was best to implement the custom simple, lightweight solution that I ended up with, but I only got away with it because I had an extremely simple FIX use case. I was only connecting a single session to a single counterparty with a single version of FIX and, apart from the login and heartbeat messages, just a single message. Had we needed multi-asset coverage or mobile trading features, the calculus would have been very different.

My problem would have been if later this was to be upgraded to another FIX version, or we had to support resend-requests, or sequence resets and gap fills. Or to offer production support and a dashboard where administering existing running sessions on the live system. Those operational requirements—monitoring, observability, user entitlement management, and secure handling of personal data—often dwarf the initial coding effort, especially for financial institutions subject to stringent compliance rules.

Image 2. Example dashboard for FIX sessions

At this point, it becomes a serious undertaking, and it starts to make more sense to turn to a tried and tested solution, already with all these bells and whistles. To use products with the ability to search historic FIX messages: such features advance both risk management and data analysis because support staff can reconstruct trading decisions in seconds.

Image 3. Searching for all FIX messages with a given client order id.

and which raise alerts when sessions disconnect: proactive alerting is essential for algorithmic trading desks that need to execute trades automatically without unexpected downtime.

Image 4. Alerts being raised in FIX UI

Not long after, I joined a company founded by Peter Lawrey called Chronicle Software; Peter is one of those super-optimal developers I mentioned earlier. He developed the widely used open-source software Chronicle Queue and Chronicle Map. We, together, set to work and built such a FIX engine that has all these bells and whistles, and in doing so, we also built a company that has grown to a team of over 20 people. Chronicle FIX follows this low-latency, low-object-creation mantra that I always envied. Now it’s being used by companies worldwide, including large investment banks, adopting it across their whole organisation. As a specialist financial software development company, Chronicle offers platform development services that bridge the gap between raw performance and enterprise-grade maintainability.

Looking back, developers can save time and effort using a buy-and-build software solution like Chronicle FIX. As mentioned, I would have been stuck if we had wanted to provide production support with my simple solution. Moreover, I certainly would have needed more time to build a UI. The lesson learnt was “Sometimes time spent reinventing the wheel results in a revolutionary new rolling device. But sometimes it just amounts to time spent reinventing the wheel.” Today, when clients ask whether they should develop an entire custom trading platform or leverage Chronicle’s proven components, our advice is clear: focus your internal resources on proprietary trading strategies and let a trusted partner supply the foundational building blocks that deliver real time market connectivity, high-availability trading bots, and robust customer support tool-sets out of the box.