Train the model. Test what it learns.
We turn research questions into language models and trading algorithms. Each has a defined task, data it can learn from and a separate test of whether the result is useful.
Learning to work with financial language.
We train language models from scratch and adapt existing models to financial tasks. Our work centres on company disclosures, news and research material.
A language model learns relationships in text. In causal language modelling, it predicts the next token, a small unit of text, from the preceding context. Training compares that prediction with the target and updates the model's trainable weights.
Learning to predict text is not the same as learning to trade. We evaluate language tasks separately from the market signals and strategies that may use their outputs.
Training, context and evaluation
Training from scratch starts without pretrained weights. Adapting an existing model builds on what it has already learned; fine-tuning uses selected examples or tasks to update its trainable weights. Providing a prompt or retrieved documents does not, by itself, retrain the model.
Validation helps choose a model and its settings. A separate test set is reserved for final evaluation. For time-sensitive financial tasks, the information available at each date also matters.
The training loop
Repeat with updated weights
From market data
to a testable signal.
Trading algorithms can use explicit rules, statistical models or learned representations. This conceptual example combines prices, trading activity and information from text to form a candidate signal. Its usefulness has to be established through testing.
Observe
Combine Representations & relationships
Estimate
Explore an input to trace its path through the model. Connections show how information can be combined, not a measured contribution to a prediction.
The future stays
outside the fit.
Fit on earlier observations. Select on validation data. Evaluate on a later, untouched period.
Time separation, trading costs and stability across market conditions.
Illustrative architecture with synthetic inputs and outputs. This is a conceptual view of the research process, not a live model, an exact production architecture or a performance result.
Prices and volatility are represented as time-ordered features. Transformations must be fitted using training data only.
Trades and market depth describe buying and selling pressure, available liquidity and execution conditions.
Text is represented as tokens and embeddings, aligned to when the information became available.
Look beyond the best setting.
A strategy depends on choices such as lookback windows and decision thresholds. We vary those choices to see whether the result persists nearby, or depends on one unusually favourable setting.
A backtest is an experiment.
A backtest simulates how a specified strategy would have behaved on historical data. We examine the assumptions behind that simulation as carefully as the result.
- Available information
- Respect publication dates, revisions and the instruments that existed at the time. Fit data transformations on the training window, not the full history.
- Unseen periods
- Develop on earlier data and evaluate forward. Keep final test results out of model selection; repeatedly tuning against the test turns it into development data.
- Trading conditions
- Account for fees, spreads, slippage, liquidity and execution delays. Compare against simple baselines and record how many alternatives were tried.
Build around what the work supports.
Useful findings can inform an analytical tool, an assistant or an automated system. Software engineering makes those ideas usable, observable and repeatable.