Inspiration

We wanted to treat Munich’s real‑world signals like market data and build a trading stack that actually runs, not just a slide demo.​​ The IMCity challenge gave us some useful, but imperfect city information, so we focused on turning it into a clean feature set for models to become competitive in the trading and forecasting challenge.​​

What it does

Our system ingests Eisbach gauge data, engineers time‑series features, and feeds them into an ensemble of XGBoost and random forest models that produce trading signals for the IMC exchange.​​ We also tried ARIMA for classical time series forecasting, but dropped it once the tree based models performed well enough and handled the changing conditions in the challenge more robustly.​​

How we built it

Everything runs in Python on Google Cloud VMs: the pipeline pulls data, builds features, trains XGBoost and random forest models, and runs backtests and live simulations.​​ We used distributed compute for faster experiments and added structured logging around data ingestion, model outputs, and trades so we can trace every decision the system makes.​​

Challenges we ran into

The main modeling challenge was balancing complexity and robustness: ARIMA was quite fragile on short noisy histories, while ensembles needed tuning to avoid overfitting different market regimes.​​ Running everything in the cloud under time pressure surfaced the usual reliability issuesfailed jobs, misconfigured permissions, and silent data bugs, so we had to rely heavily on logging and good coding practice.​​

Accomplishments that we're proud of

We finished with an ensemble that produced stable, sensible signals instead of a black box we were afraid to touch before evaluation.​​ The pipeline stayed up for the whole challenge: fresh data in, logged trades out, no manual patching during the important rounds.​​

What we learned

Most of the real work sits in data quality (and quantity), features, and reliability - once those are solid, picking between modern models matters less than people think.​​ Good logging and interpretable signals made it much easier to debug, argue about model behavior as a team, and quickly ship changes without breaking everything.​​

What's next for Bavariance IMCity

Next, we want to plug in more IMCity signals (weather, traffic, events), keep the ensemble approach, and add smarter model selection and calibration on top.​​ We also plan to harden the infrastructure with dashboards and alerts so the same codebase can support longer‑running experiments and more realistic trading setups beyond the hackathon.​​

Share this project:

Updates