Ilse | Devpost

Why did we call our Project Ilse?

It originated of a funny misspell of one teammate from KIT who thought Isar was called Ilse.

Inspiration

In the world of high-frequency trading, speed is often king. But we wanted to explore a different edge: Alternative Data. We were inspired by the idea that physical world events, e.g., planes landing, rivers rising, weather changing, directly impact economic value. Our goal was to participate on both, buy-side and sell-side. For buy-side, we leveraged alternative data to get an expected value on which we based our trading system. For sell-side, we developed a volatility-adaptive market maker to systematically exploit order book inefficiencies.

What it does

Ilse is a multi-strategy trading bot designed for the IMC simulated exchange.

Flight Derivatives: Predicts settlement prices based on real-time flight arrivals and departures at Munich Airport (MUC) using the AeroDataBox API.
Eisbach Derivatives: Models the settlement value of "Eisbach" contracts by scraping real-time water levels and flow rates of the Isar river from Bavarian state sensors.
Weather Derivatives: Forecasts settlement prices based on temperature and humidity predictions for Munich, scraping and interpolating data from TimeAndDate.com.
Market Making: Provides liquidity to the entire exchange (8 markets) using a custom inventory-skewed market making algorithm that adapts to volatility and position limits.

How we built it

We built the entire system, focusing on modularity and scalability:

FlightBot: We started by developing one single bot for a market to gain some first experience how to develop a good strategy and estimate the expected settlement.
MasterBot Architecture: To handle strict API rate limits, we built a MasterBot that acts as a central nervous system. It manages a single SSE (Server-Sent Events) connection to the exchange and orchestrates multiple strategy instances. It batches orders from all strategies into optimized API calls, ensuring we never hit rate limits while trading on all markets simultaneously.

Challenges we ran into

API Rate Limits: The exchange enforced strict limits on order updates. Our initial approach of having one bot per market crashed immediately. We had to re-architect the entire system into the MasterBot pattern to batch requests.
Data Gaps: Weather data was only available in hourly chunks, but settlement happened every minute. We had to implement robust interpolation algorithms in pandas to smooth out the data and avoid "step" artifacts in our pricing.

What we learned

Market Microstructure: We gained a deep understanding of how order books work and how spread and inventory risk interact.
Alternative Data: Real-world data is never clean.
Architecture Matters: A good initial design (separation of concerns between Strategy and Execution) saved us hours of debugging later on.

What's next for Ilse

We are happy to gain some experiences of the mechanisms a market maker has to be profitable and make money.
Also, we understood why market makers are important for all market participants to benefit from a narrow bit-ask spread.