Fintech Larper: Learning MLOps by Predicting Stock Prices
2026-10-01
A little while ago I created a GitHub repository with a simple goal: get better at CI/CD and eventually continuous training.
The repo started as cicd-course. There wasn't really a project inside
it. The project was learning the infrastructure: GitHub Actions,
testing, Docker, and eventually things like MLflow, Terraform,
Kubernetes, Argo and monitoring.
That worked for a while, but I was basically building infrastructure around nothing. I could keep inventing tiny applications just to have something to containerize and deploy, but that started to feel backwards. If I wanted to learn MLOps properly, I wanted an actual ML problem that would give the infrastructure a reason to exist.
So cicd-course became fintech-larping.
The name is intentionally unserious. I am not a quantitative researcher, and this isn't my attempt to build the next hedge fund. I'm using stock-price forecasting as a problem to learn from, both on the ML side and on the infrastructure side.
Why financial time series?
During my summer internship at Instabee I worked with time-series forecasting, mainly around forecasting parcel volumes. That got me much more interested in forecasting and gave me experience with things like seasonality, unusual periods, predictors and evaluating forecasts over time.
After the internship, I wanted to take what I had learned into a completely different domain where I could make more of the decisions myself.
Financial data seemed like a fun choice. Historical data is relatively accessible, there is a lot to learn, and it is a problem where getting a nice-looking forecast definitely doesn't mean you have built a good model.
That last part is probably going to cause me some pain.
The idea
The plan is to take a basket of stocks and forecast their daily closing prices, with each stock treated as its own time series.
Instead of looking only at tomorrow, I currently want to experiment with three horizons:
- next trading day
- next five trading days
- next twenty trading days
For the longer horizons, I want to forecast the full path rather than only the final price.
I also want the forecasts to represent uncertainty. Saying that a stock
will be worth exactly $201.34 tomorrow looks much more certain than a
forecasting model really is, so where possible I want to produce
prediction intervals and evaluate those alongside the point forecasts.
The main experiment will compare three approaches.
1. Zero-shot foundation model
This is one of the parts I'm most interested in.
While working with forecasting during my internship, I also did some reading and research on newer approaches, particularly time-series foundation models. I've wanted to explore them properly ever since.
The idea of taking a model pretrained across large collections of time series, giving it a completely new series and asking it to forecast zero-shot is fascinating to me.
For this project, I want to see what one of these models can do with historical stock prices without being trained specifically on those stocks.
2. Adapted pretrained model
The second approach will take a pretrained model and adapt it to the problem, potentially through fine-tuning.
This gives me an interesting comparison: if a general model can already forecast zero-shot, how much do we gain by adapting one to financial data?
The exact model and adaptation method will come later, after I have looked more closely at the available models and their capabilities.
3. A model trained by me
The third approach will be a custom model trained specifically for this problem.
This gives me more control over the model, features and training procedure, and later it could also become the place where I experiment with additional market variables.
Alongside all three will be the boring model that might embarrass them: a naive baseline.
Stock prices are highly persistent, so simply staying close to the latest observed price can already be difficult to beat. That makes the baseline an important sanity check rather than just another model in the comparison.
Keeping V1 manageable
It would be very easy to turn this into a huge project.
Stock prices are influenced by much more than their own history: volume, the broader market, interest rates, earnings, fundamentals, volatility, news, sentiment, politics and plenty of other things.
For V1, I want a clean price-history-only benchmark that every model can participate in.
I may also try a few simple variables such as volume or broad-market returns where the model supports them. A more ambitious V2 could eventually bring in macroeconomic data, fundamentals, news or sentiment, but I don't want to start there.
There is a technical reason for this too. Not every foundation model supports arbitrary external variables, so keeping a common univariate benchmark gives me a much cleaner comparison.
The obvious limitations
Predicting stock prices comes with a pretty important limitation: the future is not contained in the historical price chart.
Unexpected earnings, economic decisions, geopolitical events and new information can move markets tomorrow regardless of what yesterday's time series looked like.
Because of that, the evaluation is going to matter a lot. I plan to use chronological walk-forward evaluation, where models only see information that would actually have been available at the time of each forecast.
Train using data available up to day t
↓
Forecast the future
↓
Move forward
↓
Repeat
All approaches will be evaluated on the same stocks, dates and horizons.
The uncertainty estimates need to be evaluated too. A prediction interval isn't useful just because the real price falls inside it if the interval is absurdly wide.
And this is a forecasting project, not a trading system. I'm not currently turning the predictions into trading signals, position sizing, execution and portfolio returns. That would be another project on top of this one.
If the sophisticated models end up losing to the naive baseline, that's still a useful result. The point is to build the experiment properly, not to force an impressive result out of it.
The MLOps part
The original reason for creating the repository hasn't disappeared. I still want to use this project to learn CI/CD and MLOps.
I already have the beginning of the workflow in place with feature branches, pull requests, GitHub Actions, linting and automated PR review.
As the ML side grows, I want the infrastructure to grow with it: automated tests, Docker, MLflow, cloud infrastructure, Terraform, Kubernetes, Helm, GitOps, workflow orchestration and monitoring.
But I don't want to add all of that immediately just to tick boxes.
I'd rather introduce each tool when the project gives me a reason to use it. MLflow when experiments become difficult to track manually. Docker when I need reproducible environments outside my machine. Terraform when I actually have infrastructure worth reproducing.
The same applies to continuous training.
New market data arriving every day doesn't automatically mean the model needs to be retrained every day. Daily inference and daily training are different things, and different model types may need completely different retraining strategies.
I'll decide that later based on what the experiments actually show rather than adding continuous training just because it was part of the original roadmap.
What's next?
For now, the next steps are much less exciting than foundation models or Kubernetes.
I need to choose the stocks and data source, understand the data, deal with trading days and corporate actions, decide how to handle adjusted versus raw prices, explore the series and build the evaluation setup.
I'm also spending time reading and watching university material on financial time series alongside the implementation. I like learning by building things, but I don't want to end up knowing which Python function to call without understanding why I'm calling it.
This is just the starting point for Fintech Larper, and there are intentionally still a lot of unanswered questions.
I'll probably write more posts as I build it, especially around the foundation-model experiments, evaluation results and the MLOps infrastructure as it starts becoming useful.
For now, I've successfully turned a repo for learning CI/CD into a project where I also need to learn more finance.
Scope management is going great.