Skip to content
Monolith Research
Selected work / Research & engineering

Research thinking. Engineering follow-through.

Bilal Malik. Finance student at Lancaster University and founder of Monolith Research. Building the skills to take a market question all the way to a testable implementation.

Contact Bilal Background & experience
United KingdomSystematic research · Python · DataIndependent research

The relevant part.

I built Monolith to work on the complete research problem: not just generating an idea, but sourcing the data, writing the implementation, defining the test and explaining what the result can support.

That means moving between financial reasoning, statistics and practical software engineering. It also means recognising when the problem is the measurement, the clock or the cost model—not the sophistication of the algorithm.

A useful researcher should be able to explain both the idea and the code that tests it.

The work below gives you concrete entry points for a technical conversation. Private execution details stay private; the public material makes the approach inspectable.

01Selected technical work
The research toolkit
More than a score.
Statistical inferencePSR / DSR
Selection riskPBO
ReproducibilityCode / context
01 / Quantitative software

The validation framework

A public implementation surface for discussing statistical uncertainty, repeated search and backtest overfitting. The engineering question: can the decision be inspected rather than merely asserted?

Inspect the framework ↗
02

Research infrastructure

Data availability, reproducible experiments and operational separation from live execution.

03

Archived-system analysis

Distinguishing a strategy specification, a simulation and a broker-observed result.

04

Alternative-data research

A forecasting question that exposes the difference between predicting a release and earning a trading return.

Research practice

Comfortable across
the whole problem.

The strongest contribution is the connection between disciplines—not a list of tools without a reason for using them.

  1. Market reasoning

    Translate a proposed effect into a mechanism, a counter-explanation and a decisive test.

  2. Research implementation

    Work in Python on data preparation, model logic, portfolio construction and experiment outputs.

  3. Critical evaluation

    Identify leakage, selection effects, inconsistent accounting and the limits of short samples.

  4. Technical communication

    Write an evidence-led account that lets another person understand what was built and what remains uncertain.

Good questions
for an interview.

  • How would you distinguish point-in-time data from a historically revised series?
  • What does a high Sharpe ratio fail to tell you?
  • Why can a strong forecast be a poor trading strategy?
  • How would you verify that a strategy replay matches the original system?
  • Which parts of a research workflow should fail closed?

These are questions the projects make concrete. I am interested in research, markets and engineering roles where that combination is useful.

Start a conversation

Let’s talk about the work.

bilal@monolithresearch.uk ↗
Public repositories ↗LinkedIn ↗Request CV →

Monolith Research · monolithresearch.uk · bilal@monolithresearch.uk