FPGA Hardware at Optiver: Making impact at speed and scale

Hardware

Meet Kevin Sprague, Hardware Engineering Lead at Optiver. He joined as an FPGA Engineer in 2015 and now plays a key role in designing bespoke hardware solutions built to perform under the demands of modern markets.

Rich Text Block

In this article, Kevin shares how that work plays out in practice and the engineering culture that’s kept him here ever since.  

I joined Optiver from a startup almost a decade ago, looking for the chance to solve meaningful engineering problems with direct, real-world impact. At the time, FPGAs were often associated with high-speed “auto trading”—absorbing market data and adjusting orders in real time. That still matters. But here, hardware has evolved into far more than that. It’s a strategic pillar—shaping how we trade, manage risk and expand across global markets.

All of that excites me, but it can sound abstract. I’d like to share more about what it looks like in practice: how we manage complexity, iterate quickly, and how hardware engineers at Optiver make an impact.

Evolving markets, evolving hardware

That’s where hardware, and specifically FPGAs, come in. In options market making, at a given moment we’re quoting thousands of financial instruments at once–such as options, futures, ETFs, cash equities or bonds, often across multiple venues with unique protocols, expiry structures and throttling rules. It’s not enough to be fast for one trade, we need performance that holds up across everything we do.

Over the last decade, capital markets have drastically changed. Exchanges have become more deterministic and competition has increased. We see more data, more signals—and more opportunity. But to capture that, we need more than just speed. We need systems that are precise, scalable and built to handle complexity in real time.

FPGAs allow us to stay ahead by enabling rapid, real-time adjustments to trading algorithms and processing vast amounts of data with minimal delay. And because our systems need to respond deterministically—delivering the same performance, no matter the load or market condition—we go deep into how we design and deploy our hardware in relation to the whole stack. What’s really changed is the willingness of the industry to invest in genuine customization and tailoring hardware to the needs of live market data at scale.

Bespoke solutions to manage complexity

We operate on numerous global exchanges each with different protocols, throttling rules and regulatory nuances. We also support various trading products and teams, such as D1 Futures, Single Stock Options (SSO), and Index, each with unique system requirements. Every product demands its own distinct approach and design tailored for the specific strategies of the team involved.

Managing this complexity means we can’t afford to rely on off-the-shelf solutions. We need tailored hardware that supports varied trading approaches while maintaining the speed and reliability our systems demand.

A question I often ask is: how do we make our systems perform just as well for a single expiry when we’re also trading 20 more? How do we make our systems perform as well for trading one instrument when we want to trade all of them?

Our goal is not a single hardware platform, but to have a foundation that is versatile enough to adapt and accommodate varied demands without needing to rebuild everything from scratch. That takes a deep understanding of both the trading strategies and the engineering constraints. If a board-level limitation or vendor tool is slowing us down, we’ll solve it—whether internally or by partnering with chip vendors like 

to remove bottlenecks or enable new capabilities. We actively identify performance barriers or a missing FPGA feature and actively seek a solution.

Statement Block

Our guiding principle is simple: if it helps us trade better and faster—and we can manage the risk—we do it.

rich text 2

This willingness to solve problems head-on is what drives innovation and keeps us competitive within our risk appetite.

Cross-functional teamwork that powers real outcomes

Managing that level of complexity doesn’t happen in isolation. We work side by side with traders, software engineers and quants to decide where FPGAs can make the biggest impact.  

I’ve always championed this approach. It means we’re not blindly coding VHDL and handing it over; we’re understanding the trading strategies behind those signals. If you go to some firms, it’s siloed: “Let me write this code, that’s all I know, and that’s it.” Here, it’s more like, “What problem are we trying to solve? What are we actually trying to accomplish? Then we design systems and write code to solve that problem.”

It’s a constant dialogue—whiteboard sessions, code reviews, deep dives—on how to handle more signals, more data and more complexity. No single team dictates the direction; we figure it out together to our trading systems flexible and robust.

Statement Block

By embedding hardware in every decision, from how we plan to scale to how we integrate new trading signals, we maintain a real edge over firms that rely on generic solutions.

Rich Text Block 3

Fast iteration built into how we work  

There’s a myth out there that hardware development has to be slow: proposals, sign-offs, six-month rollouts and countless meetings in between. But when you’re working with the right people on the highest-priority problems, there’s no need to slow down.

We’re not content with hardware updates on a six-month cycle. We want to go from idea to code to verification to release in hours or days, always measuring the real impact in live trading. We still manage risk carefully—through thorough automated testing, simulations and peer reviews—but we don’t let unnecessary processes slow us down.

We group people around problems, shuffle teams as needed and create new roles if it helps us move faster. Our flat structure lets good ideas and real results drive progress, without waiting on traditional career steps. That meritocratic mindset is a big part of why I joined from a startup. I wanted to be somewhere ideas could move quickly, and you didn’t need a special job title to fix something that matters.

Looking ahead

As markets become more data-intensive, the demands on speed, scalability, and reliability keep rising. That’s where hardware continues to play a bigger role. At Optiver, we move quickly, work closely across teams, and build the systems we actually need—rather than relying on generic solutions. That approach helps us stay ready for whatever the markets throw at us.

If you’re a hardware engineer who enjoys complex, fast-moving problems and wants to see the impact of your work in live trading, you’ll probably find a lot to like here.

Explore our openings

Insights Related Articles

We sat down with Pat Cooney, Head of Platform Engineering, to talk about what Platform Engineering means here and where agentic AI fits into the picture. Pat has spent over a decade at Optiver across markets, regions, and roles.

When people talk about developer productivity, they often jump straight to tools: powerful coding agents, faster compilers, smarter automation. These things matter, but they are not the whole story.

Pushing Postgres beyond storage

Software

In most systems, the database acts as a boundary. You write data into it, and other systems read from it. If you need something more dynamic, like reacting to changes as they happen, you usually introduce something alongside it, whether that is a service layer, a queue, or a stream.

Large language models (LLMs) are getting surprisingly good at learning the basics of trading. Consider that the latest models are able to perform tasks like pricing simple scenarios, reasoning through rules and even outlining basic strategies.

UI as a Systems Problem

Data Engineering

If a UI doesn’t feel instant, it feels broken and users start to question what they’re seeing. A grid lags, values don’t update when expected, or a filter that used to feel instant starts to slow down. In high-demand systems like a trader’s workstation, a single desktop may be running many latency-sensitive applications at once, all competing for CPU, memory, and network bandwidth, so issues can show up quickly.

When Speed and Scale Collide

Data Engineering

Data systems are often described along two axes: speed and scale. In practice, “speed” usually means some combination of latency and throughput, and systems are often optimized for one at the expense of the other, sometimes by trading efficiency for raw capacity. Those distinctions tend to break down quickly once systems move beyond simple use cases. Once a system is both data-heavy and interactive, speed and scale stop being independent variables. Decisions made to improve one almost always affect the other, sometimes in ways that are not immediately obvious and only surface under real usage.

Click below

Learn more about Optiver