Inspiration
Our inspiration was to move beyond traditional financial models and embrace the core challenge of IMCity: trading correlated, non-stationary, real-world data. We aimed to be the fastest liquidity provider on the CMI Exchange by developing a bot that could mathematically prove the connection between the flow of the Eisbach River, Munich's weather, and the city's overall flight traffic. We sought to build a single, unified risk engine capable of managing positions across all 8 complex markets simultaneously, particularly targeting the double points available from the Munich ETF (Market 7).
What it does
The bot functions as an automated, high-frequency Market Maker (MM) across all 8 tradable products. It ensures continuous liquidity by simultaneously posting competitive Bid (buy) and Ask (sell) quotes. Its primary objectives are:
Price Discovery: Accurately predicting the future fair value ($\mu$) of each asset by incorporating cross-market data.
Inventory Risk Management: Skewing quotes to immediately offload any risk accumulated from adverse price movements, ensuring the team stays within the $\pm 200$ position limit.
Profit Capture: Capturing the bid-ask spread margin ($\delta$) to generate steady, low-risk returns.
How we built it
Our solution is an event-driven Python application leveraging a layered architecture:
Data Acquisition (src/data_client.py): We built a robust data pipeline responsible for low-latency market access (MOCK CMI Client) and high-latency external data fetching, including custom web scraping for the difficult, table-based Eisbach water levels (Flow Rate and Height) from the HND Bayern website.
Prediction Layer (VAR + Binomial):
Vector Autoregression (VAR): We used a single VAR model to jointly predict the returns and volatility ($\sigma^2$) for the highly correlated assets (Eisbach, Weather Sum, ETF), ensuring that the model learned how a change in water flow impacts the ETF price.
Binomial Model: A separate model handles the discrete, count-based Airport metrics.
Strategy Layer (src/market_maker.py): We implemented the optimal quoting strategy based on the Avellaneda-Stoikov (A-S) model. This uses our predicted $\mu$ and $\sigma^2$ along with the dynamic risk parameters ($\gamma$ and $\kappa$) to calculate the Reservation Price and Optimal Spread.
Monitoring & Control (Streamlit): We built a real-time Streamlit Dashboard (dashboard/app.py) using the Sidecar Pattern. This allows us to dynamically adjust the critical Risk Aversion ($\gamma$) and Order Flow ($\kappa$) parameters on the fly, instantly changing the bot's trading aggressiveness without restarting the core engine.
Challenges we ran into
Non-API Data Sources: The primary challenge was the necessity of scraping the Eisbach hydrological data from a public HTML table rather than a clean API, requiring complex parsing (BeautifulSoup) and fragile string cleaning logic.
Stationarity for VAR: Ensuring the diverse and non-stationary raw time series data (like Temperature and Flow Rate) could be correctly scaled and differenced for stable VAR model training was complex.
System Synchronization: Maintaining consistency between the asynchronous low-latency CMI feed and the slower, scraped external data, and ensuring all raw data was merged, scaled, and lagged correctly before VAR execution.
Accomplishments that we're proud of
Correlation Modeling: Successfully implementing and integrating the VAR model to automatically exploit cross-market dependencies, which is a significant edge in a competition based on highly linked assets.
Dynamic Risk Management: The robust implementation of the Avellaneda-Stoikov model allowing the bot to dynamically skew quotes to liquidate risk and adhere to the strict $\pm 200$ position limit.
Real-Time Control: The functional Streamlit control panel enables us to perform live, high-impact hyperparameter tuning, essential for adapting to changing market volatility during the competition.
What we learned
We learned that in real-world quant trading, data preparation and pipeline stability are just as crucial as the underlying math. Specifically, we gained a deep appreciation for:
The difference between a mid-price forecast (VAR) and a liquidity-providing quote (A-S).
The necessity of dynamic inventory management to convert predictive alpha into net PnL.
The architectural challenge of integrating high-frequency (CMI API) and low-frequency (Web Scrape) data feeds.
What's next for IMCity
Dynamic Volatility Modeling: Replace the simple VAR volatility output with a more dedicated model to forecast time-varying volatility and correlation explicitly, providing a more robust $\sigma^2$ input for the A-S spread calculation.
Hedged Inventory: Modify the A-S framework to explicitly account for cross-market hedging, allowing the bot to take larger, correlated positions that cancel out risk (e.g., being long ETF and short a highly correlated Eisbach option).
Log in or sign up for Devpost to join the conversation.