Real projects, real impact: Amsterdam summer tech internship

In this blog post, three interns—Paul, Jacqueline, and Austin—share their experiences tackling complex challenges, collaborating with teams across the business, and seeing the direct impact of their work in production. Their insights offer a glimpse into how learning and application come together at Optiver, empowering individuals at all stages of their careers to make meaningful contributions that drive our technology forward.

AMS tech intern projects

1. Enhancing market stability: Developing dynamic price collars for extreme risk mitigation
2. Streamlining server migrations: Automating pre-migration validations
3. Optimising network efficiency: Building a connection monitoring system pipeline

Project Challenge

Mitigating autotrading risk is a crucial activity for a global market maker like Optiver, requiring the firm to develop a complex variety of systems to tackle all the different aspects of autotrading-related risk.

One key mitigation strategy is the “price collar” system, a mechanism which defines the price restrictions we set for our orders and quotes. However, since markets constantly fluctuate, the price collar needs to adapt in real time. One of the biggest challenges we face is distinguishing normal price movements from anomalies. To address this, we worked to develop a more dynamic protection strategy for the price collar system.

Approach

We used a data-driven approach to define the dynamic protection strategy. After analysing historical data, we concluded that more than 95% of market jumps are moves of less than 50%. Thus, whenever the market moves more than 50% in a single jump, we have a strong statistical indication to suspect that something could be wrong. We used this insight to define the max allowed percentage move as the trigger for this new protection strategy.

Once triggered, the relevant price collars will be invalidated. This effectively prevents new orders and quotes from being sent to the exchange for the instrument in question. Triggering the protection should also lead to the involvement of a human. A risk manager will be expected to make a judgement call on the validity of the available data. Once the protection trigger is acknowledged, price collars will be revalidated and trading can be resumed.

There are also valid situations in which large market price jumps are expected, such as in the case of a corporate action—for example, a stock split. This is why it’s important to include conscious decision-making into the resolution process.

Results

Having implemented this new dynamic protection strategy, we expanded our risk mitigation strategies with yet another control mechanism. This improves the robustness of our autotrading systems and enhances coverage against potential technical hazards. Overall, I found this project to be very impactful and interesting. It was great exposure to the complex systems we have in place to mitigate autotrading risk and allowed me to learn a lot about how Optiver’s trading is managed. Plus, I really appreciated the opportunity to collaborate with other engineers and traders to achieve the best possible outcome for the company.

Project Challenge

Optiver is currently undergoing a major transition across the backbone of our trading infrastructure, migrating all trading servers from CentOS to AlmaLinux. Along with the OS migration, we’re also standardising our global configuration and infrastructure management practices. This transition involves rebuilding our existing tools and libraries, multiple configuration updates, and detailed checks on each server to confirm that it’s ready for migration. Until now, these validation steps have been manual, making them time-consuming and prone to errors.

My project focused on automating these pre-migration validations, creating a streamlined process that enables trading production engineers to efficiently validate and migrate each server.

Approach

To tackle this challenge, I employed a structured approach, beginning with a comprehensive understanding of the various tasks involved. I collaborated closely with other teams in Infra to gain in-depth knowledge of these systems, which was crucial for the successful integration of each migration validation step. With a clear plan, I focused on developing the logic for each individual check, ensuring that the goals for each task were met. I incrementally added tests to validate the functionality of the code as it was developed, ensuring that the tool behaved as expected at each stage.

After implementing the individual migration steps, I integrated them into a single, cohesive command-line interface (CLI) tool. It was essential to design the tool in a clean and modular manner, allowing for easy addition of new tasks or checks in the future. Usability was a key consideration, ensuring the tool was configurable and fit the workflow of targeted users. Following the completion of the initial version of the tool, I gathered feedback from users within my team and across the Infrastructure department. This feedback loop led to continuous development, with each iteration enhancing the tool’s functionality based on real-world usage and suggestions.

Result

The final product is a command-line tool that automates the validation and conversion processes, determining whether a server is ready for migration, while also providing detailed information on any issues encountered during the process.

Working on this project was both challenging and rewarding. It gave me deep insight into Optiver’s trading infrastructure and configuration management processes and the overall OS migration workflow. Seeing the tool’s positive impact on the team and the company’s operations has been especially fulfilling.

Project Challenge

A critical part of operating a trading firm is ensuring that network connections are efficient and performing within capacity. Optiver’s existing capacity monitoring system in Amsterdam tracks live connections between applications, helping the trading system run smoothly. My project involved developing a similar connection monitoring system for the US region, with goals to improve insights into trading performance and gather key metrics on network efficiency and application behaviour.

This project posed several challenges. First, I needed to minimise the CPU load of the new monitoring service as it would be running on every host in the trading environment. Additionally, I needed to adapt my design to use a different data pipeline to send metrics into regional databases.

Approach

To tackle the challenge, I began by profiling the existing system to identify bottlenecks and potential improvements. I wanted to understand how the system handled large numbers of connections, and assess ways to reduce the impact of scaling up.

A key breakthrough came from exploring the Linux kernel source code to find faster ways of collecting TCP and memory metrics. The current system parsed metrics from the Linux command line, but I experimented with alternative approaches, such as using low-level C libraries to directly access metrics from system files, eliminating the need for parsing and reducing CPU load.

Building the new data pipeline required me to learn about in-house communication protocols as well as open-source technologies like Kafka, and extend protocol libraries in ways relevant to both my project and future monitoring systems. Given the scope of my project, effective communication with engineers across teams, departments, and other offices was vital, highlighting the intricacies of how a global trading firm operates.

Result

One of the key outcomes of my project was writing the first Python client library to communicate over a custom protocol to the in-house Kafka publishing system. This allowed connection metrics data to be published in the regional metrics database, enabling the future usage of other metrics to be collected.

While my primary focus was building a new connection monitoring system for the US region, a beneficial byproduct of my project was that I also successfully reduced the load on the existing monitoring system in Amsterdam by implementing a local caching layer, resulting in a 28.5% decrease in database load. My changes were rolled out to over 1,400 components in production.

Cache changes reducing the load on the existing monitoring system

Are you our next intern?

Apply now for our 2026 Amsterdam internship program and get ready for a 10-week immersive learning experience.