Software engineering at a proprietary trading company: Optiver

Building better AI models getting more focus than lower latency, 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:

Alex Itkin: CTO, Optiver US
Pat Cooney: Head of Global Platform Engineering
David Gross: Technology Lead, Options

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:

No external customers.Usually, companies have consumer customers (B2C), business customers (B2B), or both. But not trading houses like Optiver, where their own business is- thecustomer. This is a different reality: there’s no external deadlines and related pressures, but personal motivation to improve is highly valued.
Latency: “enemy number one”.Nearly every major engineering decision at Optiver is made in the interest of minimizing latency – the amount of time between a request and response. This approach is present across the software stack and in kernel-level work. It’s why Optiver manufactures its own hardware.
Today, latency is the floor, and AI models are becoming a differentiator.Gone are the days of having lower latency than the competition allowing for arbitrage opportunities to make risk-free profits. Instead, information models are becoming a differentiator: slow models with a fast trigger sending signals to execute trades, and fast models running at the edge of the network making trade decisions realtime.
Haunted by a bug that nearly killed a business.Among trading houses, there’s a cautionary tale of when a peer company, Knight Capital, nearly went bankrupt after a single bug in a high-frequency trading system triggered a $440M loss.
Different incentives.The business is incentivized to move very fast, but with a high premium on caution in order to avert potential financial disasters on the market. This cautious attitude to risk in concert with chasing speed feels pretty distinct in tech.

I this deepdive, we cover:

Overview of trading & hedge funds.Categories of trading companies, high-frequency trading (HFT), plenty of ML & math, and AI labs poaching HFT talent
Engineering organization.How trading-specific roles work together, platform engineering, the “build and own” culture, and more.
Software tech stack.The three-layer tech stack, languages and tools, CI/CD stack and the data layer.
Hardware engineering, FPGAs and Silicon.Latency progression, custom FPGAs, custom hardware, AMD hardware partnership, and more.
Network & physical infrastructure.Physical infrastructure, dedicated fiber & wavelength leasing, optical cable, radio, data centers & co-locations, and why AI models matter more than ever before.
Engineering practices.Risk vs speed, knowledge-sharing culture, testing culture, monitoring & incident detection, risk management.
AI at Optiver.AI tooling stack, future of agentic coding, details about adoption, and how it all looks in practice.
Hiring, career development & culture.Engineering levels at Optiver, going

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 funds

Here’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 operates

Buy side/sell side

Buy side:companies invest money and earn returns. Examples: hedge funds, asset managers, pension funds.
Sell side:firms sell services or products such as advice, underwriting, research, execution, etc. These are usually investment banks and broker-dealers.

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:

Investment banksserve corporate and institutional clients by raising capital, advising on deals, and executing trades on their behalf. Examples: Goldman Sachs, JPMorgan, Morgan Stanley.
Hedge fundsraise money from external investors and trade it on their behalf, charging management & performance fees. Examples: Citadel, Millennium, Two Sigma, Bridgewater.
Proprietary trading firmstrade only their own capital, with no clients or external funding. Examples: Optiver, Jane Street, Jump Trading, DRW, Hudson River Trading.

Trading eras

Optiver’s CTO US Alex Itkin pictures the evolution of trading as having unfolded across four eras to date:

Pre-electronic (pre-1990s).Trading was done face-to-face on noisy trading floors and by phone. Prices were shared on reels of ticker tape and printed in newspapers. Investors contacted brokers to place orders.
First wave of electronification (early/mid 1990s).Financial markets moved onto computer screens but orders were still entered manually.
Automated trading (late 1990s to ~2015).Computers did the same as human traders, but faster and at scale. This was the “mechanical” automation era of building automated workflows without data-driven decision-making.
Quantitative trading (~2015 to present).Data-driven decision-making with machine learning models and inference compute, with human decision-making in some key areas.

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 glance

Optiver turned 40 years old in March 2026, launching in 1986 at the European Options Exchange. Today, the company has:

~2,200employees
~950engineers and ~1,000 traders and researchers
11- offices: Amsterdam (HQ), Chicago (US HQ), Austin, New York (2025), London, Sydney, Shanghai, Hong Kong, Singapore, Taipei, and Mumbai.
10M+trades executed per day, across 100 exchanges
€4.5B($5.1B) in trading income, and €1.7B ($1.95B) profit, as per 2025 financial results

Optiver is a mix of:

Market maker: providing liquidity on exchanges by quoting ‘buy’ and ‘sell’ prices of financial products and earning the spread between the two.
High-frequency trader:executing automated trading strategies at very low latency

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:

Watchthe market for new information like price changes
Decidewhat the information means and the right trade to make
Senda trade to the exchange before competitors do

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 & math

There’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 talent

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

Infra expertise.Prop shops like Optiver have spent decades operating their own data centers and deploying on-prem hardware at co-location facilities.
Custom, high-performance hardware.Prop shops also often build their own hardware and their kernel stacks achieve very low latencies. That’s a talent AI labs seek!
Skillsets.The highest-paying destinations for CS majors out of standout colleges are often prop shops, paying top-of-market compensation for standout talent.- Outside of select colleges prop shops recruit from, however, there tends to be little awareness about these companies for new grads, or across the industry.

2. Engineering organization

Two eras of Optiver tech

Optiver’s history can be seen as two distinct ages:

Regional systems (“unblock yourself”: 1986-2020):internal systems and platforms were built to serve local needs, such as building support for a market. Systems built exclusively for the US, Europe, or Asia were common.
Global platforms (“build for the whole company”: 2020-present):Optiver recently started to build new systems to work globally across their platform. This global focus is also why the company is investing a lot more in its platform engineering arm. A globalization push started around 2023, and its momentum has been growing.

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:

Fragmentation: different teams use different technologies, frameworks, and infrastructure
Duplication: teams in different parts of the business independently build the same or very similar services

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:

Build for scale:create a CI system built to scale across regions and stand the test of time
Use from any region:standardize deployment pipelines, so that code built in one location can run anywhere without friction

How roles work together

At Optiver, there are three main areas for tech roles:

Engineering: build and own the full trading-platform stack
Research: quantitative scientists who build models and predictive signals to create and improve trading algorithms. Typically, their background is in math, physics, economics, and statistics
Trading: quantitative traders who watch live markets, adjust trading system parameters in response to conditions, and build tools to automate decisions

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 engineering

Before Optiver’s globalized platform efforts started seriously in ~2023, regions duplicated effort:

Multiple implementations of identical core logic
Each region had its own systems, frameworks, and infrastructure
Local teams built whatever they needed in an “unblock yourself” culture

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:

AI gateway: gives Optiver engineers access to models
MCP hosting platform:makes it easy for engineers to access internal systems and tools via agents

How trading teams are organized

Trading teams at Optiver have three roles:

Traders decide strategy and make risk decisions
Researchers and quantitative analysts (“quants”) build hypotheses, pricing models, and run evaluations
Engineers build production systems

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

A large team is focused on a broad area like - options
A team focused on - cash marketsand building strategies for exchange-traded funds (ETF) and stocks.
A team focused on machine learning (ML) and trading in the - cash market.

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.

Retrieval of market-related information
Collecting signals to work out which trades to execute
Execution of strategies (sending orders to market)
Intervention via a feedback loop, enabling a trader to monitor the system.

“Build and own” culture

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

Traders and engineers define problems together.Engineers design, build, test, deploy, and monitor a solution. There are hundreds of production changes daily
Design reviews for architectural decision-making.When an engineer has a project that entails architectural change to the stack, the engineer is responsible for bringing multiple options with the pros and cons to the team for consultation. The goal is to share information and knowledge, and to make decisions

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 Org

Optiver 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 structures

Vertical 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 stack

Basic trading loop & three-layer tech stack

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

Signals

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

Strategy

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

Execution

The 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 loop

In 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 layers

All apps implementing the trading loop sit on top of a multi-layered internal platform:

Basic infrastructure layer: the stuff you’d see at most tech companies (CI/CD pipelines, k8s, Kafka, Postgres, etc), but they’re also customizing their stack. They run their own data centers, have custom hardware, custom Linux kernels, customized CI tooling, and databases.
Domain-specific infrastructurecontains core trading-specific services such as trading data dictionaries, metadata on securities, and the trade booking system.

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 tools

At 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-asyncpg: Optiver’s fork of a performance-focused async Python lib for Postgres
vulcan-py: Optiver’s own dependency manager for Python allows more granular control over indirect dependencies
opti-napalm: Optiver’s fork of a library for automating and simulating various network equipment

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:

C#for building data-intensive trader-facing GUIs,
VHDLand- SystemVerilogfor FPGA development.

CI/CD stack

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

Data

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

They contributed a new timestamp type to Postgres, allowing timestamps to be expressed with nanosecond precision. Few Postgres applications care about nanosecond-level precision, and this wasn’t available “out of the box”.
They built their own internal version of the NOTIFY - LISTEN mechanism called ‘PG Feed,’ based on Postgres’ write-ahead log. This is used for distributing high-fanout, latency-sensitive messages to clients like pricing and configuration data, whereas using something like Kafka may involve additional disk reads and writes, which imply unwanted latency.

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!