Software engineering at a proprietary trading company: Optiver
👋 Hi, this is Gergely with a subscriber-only issue of the Pragmatic Engineer Newsletter. In every issue, I cover challenges at Big Tech and startups through the lens of engineering managers and senior engineers. If you’ve been forwarded this email, you can subscribe here. Software engineering at a proprietary trading company: OptiverA shift from a focus on latency to building better AI models, owning the full stack from applications to building custom hardware, very different incentives to most tech companies in play, and more
Before we start: I’ll be in New York, on 15 September, presenting the keynote at LDX3 New York, doing a book signing, and hanging out with attendees. The focus of the conference is engineering leadership at a time when things are moving very fast. See the full agenda and get tickets. If you’ll be around – hopefully catch you there! The Pragmatic Engineer is back from our summer break. We resume with a detailed deepdive about the trading industry, and interesting engineering challenges that come when working at a company that has no external customers, but where a single, unfortunate enough software bug could wipe out the whole company. In tech recruitment, proprietary trading companies have a particularly high bar and typically offer compensation on a par with, or even exceeding, Big Tech; right at the top of the market. That’s because for these market makers, success is all about gaining a competitive edge over rivals. Such competitive advantages today includes software that is superior to that at their competitors. Software engineers tend to know little about trading companies – and this piece aims to change that. Trading companies build bespoke hardware stacks and have larger platform engineering teams than most workplaces. For software engineers, it’s a lucrative niche in terms of compensation, full-stack (hardware to software) work and for engineering challenges, and so we decided to go deeper in this interesting area. In order to find out more, The Pragmatic Engineer sat down with a leading proprietary trading firm, Optiver. Headquartered in Amsterdam, they also have a large engineering presence in the US and globally. We met engineers and engineering leaders to learn in depth how engineering works in a modern trading business, with contributions from:
Thanks to everyone at Optiver for taking part in this report which lifts the lid on how software engineering is done when even nanoseconds can count. In this article, we look into a software engineering environment that’s distinct from what you expect at most startups and Big Tech. For example:
I this deepdive, we cover:
We’re delighted to publish this report, including details never shared before. Let’s dive in! This deepdive is longer than most articles, due to how much new detail it shares about Optiver and the trading industry. The bottom of the article could be cut off in email clients. Read the full article uninterrupted, online. 1. Overview of trading & hedge fundsHere’s a summary of the world of ‘prop shops’; another name for firms like Optiver that invest their own funds in trading financial assets. Below are some useful mental models for understanding the sector. How trading operatesBuy side/sell side
Optiver is on the “buy side”, as a prop shop. Sources of capital
Based on whose money is being traded, there are three main capital sources:
Trading erasOptiver’s CTO US Alex Itkin pictures the evolution of trading as having unfolded across four eras to date:
Each era “weeded” the market. Some companies excelled at automated trading but never made the leap to quantitative trading. According to Itkin, competition has got tougher over time, while the number of serious players has decreased. Today, there are only a handful of really big firms, and one reason for this is cost: investment in research clusters – which serious prop shops all do – requires hundreds of millions of dollars. Optiver at a glanceOptiver turned 40 years old in March 2026, launching in 1986 at the European Options Exchange. Today, the company has:
Optiver is a mix of:
High-Frequency Trading (HFT)High-frequency trading involves placing high volumes of orders at lightning speed in an effort to take advantage of extremely rapid market movements. In this domain, speed is the biggest advantage, and achieving it obviously involves high-performance computing. The basic trading loop is run millions of times a day. It’s made up of three steps:
In trading, timing is everything, and for some types of trade even nanoseconds count. Optiver’s fastest trading system operates in the realm of sub-nanosecond, where measurement noise becomes a challenge in itself. Software, hardware, and physics are all involved, along with microwave and shortwave links between data centers, and custom-manufactured chips. We go deep into this in the “Hardware Engineering” section below. However, in this niche, even ultra-low latency is no longer a competitive moat in itself. As competitors have squeezed performance out of their systems, focus has shifted towards fine-tuning of trading strategies. Today, Optiver invests substantially more in building better models than it does in lowering latencies. More on this in the “Network and physical infrastructure” section below. HFT evolves faster than other industries. Profitable strategies don’t last long, opportunities are fleeting, and innovation is a constant. In this environment, a tool like AI is relatively straightforward to implement because trading houses like Optiver are well used to change in their daily business environment. More on this topic in the ‘Optiver & AI’ section. Plenty of ML & mathThere’s a big role for machine learning (ML) and mathematics in quantitative trading. A good chunk of Optiver’s business is the buying and selling of options, and the pricing of these rests on mathematical theorems like the Black-Scholes model. Traders, quants, and even software engineers building option-pricing strategies must understand the math of this problem space. Over time, machine learning is becoming more important than math models, but it’s worth keeping in mind that trading is not purely an ML pursuit. AI infra providers are heavily involved. NVIDIA, Groq, and Cerebras are actively courting trading firms, due to how much money they spend on GPUs. For example, see Hudson River Trading discussing Blackwell deployments at NVIDIA’s GTC conference, or Jump Trading being among the first to deploy next-gen Vera Rubin systems. HFT companies have very clear monetization paths for GPUs and spend large sums on hardware, hence why NVIDIA and other suppliers are keen to partner with them. AI labs poach trading talentOne new trend is AI labs like Anthropic and OpenAI recruiting from prop shops, defying the assumption that AI labs mostly recruit from Big Tech. There are a few reasons why AI labs seek out talent from the trading world:
2. Engineering organizationTwo eras of Optiver techOptiver’s history can be seen as two distinct ages:
The benefit of the old “unblock yourself” approach of local teams building whatever they needed, was that it enabled them to move fast and not get held up by dependencies. But this became problematic because of fragmentation and duplication, and the downsides became more visible over time:
The career trajectory of Pat Cooney, Optiver’s head of platform engineering, mirrors the shift to a global platform: he was the CTO of Optiver in Europe in the mid-2010s when the business was split by region, and was appointed head of platform engineering in 2025 when that approach was replaced. Optiver’s approach to continuous integration (CI) has also evolved. Previously, the company had several regional CI services, but from 2025, it started to rebuild its CI system with two new goals:
How roles work togetherAt Optiver, there are three main areas for tech roles:
In reality, the boundaries between these areas are porous. Yes, people do the job they were hired for, but it’s common to also see researchers roll up their sleeves and take part in implementing a trading strategy, or software engineers conducting research.
Cross-functional collaboration between roles is very common. For example, when developing market signals and associated trading strategies, it’s normal for engineers, researchers, and traders to collaborate on most, if not all, projects. End-to-end ownership, plus autonomy, is a given. Engineers have autonomy in how they get things done, and they own and solve problems from the ideas stage through to implementation. There is a limited amount of guidance for trading, and it’s down to engineers to find the right solution. In many ways, this approach to software engineering is pretty similar to startups’: software engineers get limited guidance and lots of autonomy. In order to succeed at tech startups, engineers typically need to understand the business, as well as being excellent at building production-ready software. It’s the same at Optiver, where understanding the business means understanding markets. Platform engineeringBefore Optiver’s globalized platform efforts started seriously in ~2023, regions duplicated effort:
But that’s all changed. An obvious sign of global platform efforts is the appointment of Optiver’s first global CTO, Lance Braunstein, who joined with a mandate to scale the platform. Roughly 30-40% of Optiver’s 950 engineers work on the platform. In contrast, a more typical ratio at other large tech companies is for 15-20% of engineers to be dedicated to platform work. Prior to the global platform, there was a lot more tolerance of development experience friction; new engineers could spend weeks checking out the codebase and getting their build system to work. This mindset has changed, with the platform team stressing user empathy and reducing friction on engineers’ journeys, like by setting up build pipelines for their software. Now, the platform is beginning to reimagine itself as built for AI. As agents proliferate at Optiver, users are both humans and automated systems. The goal of this shift is to empower people to decompose work into workstreams and orchestrate agents. Two projects were launched earlier this year by the platform team for agentic work:
How trading teams are organizedTrading teams at Optiver have three roles:
In practice, these roles overlap. This was true before the AI era, but it seems to be accelerating with AI adoption. Most traders and quants have STEM backgrounds without recent production coding experience. AI enables quantitatively-minded people to automate workflows with agents and to implement strategies. Trading teams are organized by asset class and strategy. For example (asset classes in italic):
Within larger teams, there are horizontal and vertical sub-teams. Horizontal teams take on challenges that impact any trading desk; for example, pricing is a horizontal team as the underlying mechanism is the same whether a soybean or an index fund being priced. Vertical teams are similar to “tiger teams”, accelerators, and program teams at other companies. They focus on short-term goals attached to a few different desks in a location like the US, Amsterdam, Mumbai or Sydney. Each team has a trading or research lead and a tech lead, who identify work for the team to do. The overall direction is set by a partnership structure, similar to an investment bank, but partners are not necessarily in charge of teams. At Optiver, partners are collections of senior people responsible for overall strategy. Regardless of asset class or vertical, every trading team builds a version of a trading loop with four components.
“Build and own” cultureOptiver runs on an ownership culture, with the principle that the best engineers take work personally and care deeply about Optiver’s systems, decisions, and outcomes. Leaders want engineers to treat their projects as if they were CEOs of a company, and be responsible for design, build, rollout, shipping, or support. There is no notion of throwing work over the wall to a QA team. Optiver’s ownership model:
Optiver pushes new hires and interns to develop ownership. From day one, engineers have something they own and are assigned a real project with mentoring support. Production code changes are an expectation for new hires. Within a year, a new hire becomes the experienced person in their domain, ramping up the next engineer. This is explicitly emphasized in Optiver’s onboarding materials:
Ownership is also baked into the interview process, with explicit questions about problem-solving, talking through trade-offs, and implementation. Case study: the Options OrgOptiver started life with options trading. The word ‘Optiver’ is actually a Dutch portmanteau of “options” and “trader”, so it’s unsurprising that the options team is among the most developed parts of the operation, with engineers split across multiple locations. The organization is composed of both vertical and horizontal teams. One of the technical systems for which the Options organization is responsible is the retreat system. When Optiver trades an option, that trade itself changes the price of the next quote on offer. The retreat system has to reprice the entire option surface (i.e., all options related to the one just traded). This is called a ‘retreat’. In the case of S&P options, the option surface can consist of thousands of options that have to be updated. Ten years ago, the retreat process took seconds; now, through optimizations at every level of the stack, it’s down to nanoseconds.
Retreat speed matters because everything changes as soon as a trade occurs: the original quote is stale and a trader needs to remove the bid from the exchange before anyone can exploit it. Faster firms can take advantage of others’ stale prices, leading to an adversarial market dynamic. Horizontal vs vertical team structuresVertical teams work on specific tactical problems related to local trading desks with a focus on immediate impact. But they are not short-term or temporary teams, even if they work on short-term problems. They’re empowered to solve the most important current problems, end-to-end. On the other hand, horizontal teams serve most desks, and have longer time horizons because they work on cross-cutting problems like pricing, market connectivity, or auto-trading. 3. Software tech stackBasic trading loop & three-layer tech stackMost trading software applications or services (aka “apps”) at Optiver can be simplified to the basic trading loop. The exchange where the trading takes place is part of the outside world from which signals are extracted:
SignalsThis is the information-gathering phase where services collect market data such as prices and order book information, and also run various data calculations, such as pricing algorithms and machine learning pipelines. These signals are made available to strategy applications/services which decide how to trade. StrategyA single trading strategy typically focuses on a particular class of assets and trades, and many different strategies run concurrently. The strategy sets what and how to trade, but doesn’t execute the trade; that’s the next step. All strategies are enveloped by a risk management system that can block trades and stop individual strategies. To be effective, it has a broader view of the combined risk level of multiple strategies. Risk mechanisms can include human oversight, with traders tweaking strategy parameters, and also automated monitoring that checks if apps are outputting orders within expected parameters, regardless of what the algorithm wants. The latter approach is essential in low latency strategies where faster-than-human reaction speeds are needed. ExecutionThe execution step involves executing trades on exchanges. There’s a hard ‘separation of concerns’ principle where execution steps are only permitted to execute the trade. No additional logic is meant to run there. Ultra low-latency loopIn some market-making use cases where nanosecond-level latencies matter, much of this process may run within a single chip (FPGA or ASIC) where the strategy part can be memoized with precomputed responses for all expected input patterns. This is then burned into the hardware to minimize latency from when market information arrives until a trading order is issued. The tech stack’s three layersAll apps implementing the trading loop sit on top of a multi-layered internal platform:
Historically, most of this infrastructure was duplicated at each local office level when teams prioritized moving fast and independently over avoiding duplication. A centralized platform team has started consolidating these efforts in recent years. Roughly 30-40% of the engineering headcount is allocated to the Platform team. This level of investment in the platform is beyond what you’d typically see in a tech company. That’s likely to remain the case for a while longer as they focus on improving the development experience, consolidating duplicated functionality, and catering to the specifics of their tech stack. Languages and toolsAt a glance:
Language choices at Optiver are fairly standard for a financial institution: C++ for low latency applications, and Python for modeling, prototyping and internal tooling work. However, looking closely at Optiver’s contributions to the Python ecosystem reveals that this language is not just a prototyping tool:
Optiver’s internal tooling also has strict performance requirements because traders use internal dashboards and tools to make time-sensitive trading decisions. Avoiding hand-offs between traders and engineers for reimplementation in C++ saves time, and empowers non-engineers to solve their problems directly, in line with the “unblock yourself” ethos. Rust is starting to play a significant role in research tooling and service orchestration, likely driven by the performance requirements. It’s interesting to see Rust used in areas such as Python, as opposed to it replacing C++, which would be obvious given its focus on performance. It’s likely due to Optiver’s decades’ worth of investment in the low-latency C++ ecosystem, its deep integration with existing internal hardware, and being able to directly control things like memory allocation with C++. Other languages used in some niche use cases include:
CI/CD stackMuch of the software that Optiver builds interacts with custom hardware, custom Linux kernels, and requires predictable compute performance for predictable results in performance tests. These are all constraints that the CI/CD stack has to operate within. Optiver’s CI/CD runs on bare metal machines, with custom hardware installed, the right OS tweaks, and a well-understood performance profile. Interestingly, this means Optiver needs to plan capacity in advance for its CI/CD clusters in the same way as it plans capacity for production systems. This is tricky since AI-coding tools started boosting the number of builds an average engineer does in a day. They chose GitHub Actions as their CI Platform for the seamless development experience with GitHub. Unfortunately, Actions doesn’t provide overall, system-level metrics like queue times and utilizations, which are critical information for planning CI cluster capacity. Therefore, they had to build a bespoke observability layer over GitHub Actions pipelines with GitHub webhooks. DataWhen it comes to databases and storage systems in general, Optiver is a big user of Kafka, Postgres, and Databricks (the company built its entire data platform around this). A few interesting details show the role of Postgres:
Optiver generally picks industry-standard tooling, but heavily tweaks it to fit their specific performance needs. Not many tech companies of this size tweak Postgres or GitHub Actions, let alone Linux kernels! 4. Hardware engineering, FPGAs and Silicon...Subscribe to The Pragmatic Engineer to unlock the rest.Become a paying subscriber of The Pragmatic Engineer to get access to this post and other subscriber-only content. A subscription gets you:
|
Comments
Post a Comment