AI Trading Book Reference
Home / Evidence / LLMs and strategy
Evidence LLMs Methodology

Can an LLM build a profitable trading strategy?

A language model can write a working strategy in a minute. That capability is real, and it is not the same as the strategy being profitable. The gap between the two is where the interesting problems live — and one of them is specific to LLMs and largely unremarked: the model has read commentary about the period you are about to backtest on. That is look-ahead bias arriving through the model rather than through your data, and a correctly ordered chronological split does not remove it.

Published 27 August 2026 · Updated 28 August 2026 · AI Trading Book Editorial · Reading time about 12 minutes

TL;DR
  • Code generation works. Strategy validation is unchanged. The model removes the typing, not the hard part.
  • The training corpus is a leakage channel. The model knows what worked in the period you are testing.
  • Cheap iteration makes overfitting worse, because the trial count explodes without you noticing.
  • Silent numerical errors are the real hazard, not obvious hallucinations.
  • Use it as a critic, not an originator. That is where it is most reliable.

The short answer

Yes, an LLM can produce a coherent trading strategy with working code, plausible entry and exit rules, position sizing and a backtest harness. Ask a current model to build a mean-reversion strategy on a liquid instrument and you will get something that runs.

No published evidence establishes that such strategies are profitable after costs against a passive benchmark. The surrounding evidence is unfavourable: a peer-reviewed review of 27 machine-learning equity experiments found no conclusive evidence of machine-learning funds delivering returns at scale, and AI hedge fund indices returned 9.8% annualised against 13.7% for the S&P 500 from December 2009 to July 2024. Nothing about a language model changes the market conditions that produced those results.

The useful framing is that an LLM compresses the engineering, which was never the bottleneck. Writing a backtest was always the easy part; establishing that its result means anything was always the hard part, and that remains exactly as hard.

What LLMs genuinely do well here

Dismissing the capability entirely would be as wrong as overselling it. Four uses hold up.

  • Code generation and debugging. Turning a described rule into working code, or finding why a backtest loop is off by one bar, is exactly the sort of task where a model saves hours.
  • Explanation. Asking what a Deflated Sharpe Ratio adjusts for, or how walk-forward validation differs from a single split, gets a reliable answer on well-documented concepts.
  • Document work. Summarising a filing, extracting structure from a regulatory consultation, or drafting a research protocol are text tasks, and text is what the model is for.
  • Adversarial review. Asking a model to list the ways your backtest could be wrong produces a genuinely useful checklist, because critiquing methodology is a well-covered topic in its training data.

None of these is prediction. That is the pattern: LLMs help with the parts of the work that are engineering and comprehension, and contribute nothing to the part that is forecasting.

The leakage problem specific to LLMs

This is the part most discussions miss, and it deserves care because it is not obvious.

Standard look-ahead bias comes from your data pipeline — shuffling a time series before splitting, scaling features using statistics from the whole dataset, using fundamentals dated before publication. The backtest overfitting page covers those. Every one of them is fixable by handling data correctly.

An LLM introduces a channel that data hygiene does not close. The model was trained on text written up to some cutoff, and that text includes an enormous quantity of financial commentary, strategy discussion, academic papers and post-hoc analysis of what worked. When you ask it to design a strategy and then backtest on a period before that cutoff, you are testing on data the model has already read about.

Two leakage channels. Only one is closed by handling your data correctly. Ordinary look-ahead bias Enters through: shuffled splits, global scaling, wrongly dated fundamentals Fixed by: chronological splits, point-in-time data, a holdout opened once Detectable: yes, by inspecting the pipeline Training-corpus leakage Enters through: the model having read commentary about your test period Not fixed by: any amount of correct data handling — the leak is in the suggestion, not the data Detectable: only by testing after the model's knowledge cutoff A perfectly clean chronological split still leaks if the strategy idea itself came from a model that read the answer.
The second channel has no data-side remedy. The only reliable test is a period the model could not have known about.

The mechanism is subtle because nothing in your pipeline is wrong. Your split is chronological, your data is point-in-time, your holdout is untouched. But the hypothesis you are testing was generated by a system that has absorbed years of writing about which approaches performed well in exactly those years — including the survivorship bias in that writing, since strategies that failed generate far less commentary than strategies that worked.

Two practical consequences. A strategy an LLM suggests will tend to look better on periods before the cutoff than after it, and that difference is a diagnostic rather than a coincidence. And the standard defence — hold out a final period and open it once — only works if that period falls after the model's knowledge cutoff.

Testing after the cutoff

The clean version is forward testing: paper trade the strategy on data that did not exist when you generated it, for a period fixed in advance. That is slow, and it is the only test that fully closes this channel.

A partial substitute is to reserve a holdout after the model's stated knowledge cutoff and treat any performance gap between the pre-cutoff and post-cutoff periods as evidence about the strategy rather than about the market. A large gap is not proof of leakage, but it removes the basis for believing the earlier result.

Cheap iteration makes the multiple-testing problem worse

Fast generation quietly inflates the trial count, which is the number that determines whether a backtest result means anything.

The arithmetic is on our overfitting page: at a 5% significance threshold, twenty independent worthless strategies give roughly a 64% chance that at least one appears significant, and a hundred pushes it past 99%. That is the same whether the variants took a week each or thirty seconds each.

Before LLMs, the cost of writing each variant imposed a natural limit — you might test twenty ideas over a month. Now you can test two hundred in an afternoon, and the ones you discarded after a glance still count as trials. Most people do not log them, so the trial count used for deflation is dramatically understated exactly when it needs to be highest.

Probability at least one worthless variant looks significant, at a 5% threshold — AI Trading Book calculation 5% 1 trial 40% 10 64% 20 92% 50 >99% 100 1 − 0.95ⁿ. An afternoon of prompting reaches the right-hand columns easily, and the discarded variants still count.
Elementary probability, computed here rather than cited. The mechanism is unchanged by LLMs; the speed of reaching the dangerous end is not.

Hallucination, and the version of it that matters

Language models invent things: indicators that do not exist, formulas that are subtly wrong, citations to papers that were never written. In a trading context the obvious cases are the least dangerous, because obviously wrong code fails loudly.

The category that causes real damage is the silent numerical error — code that runs, produces plausible output, and computes something other than what you asked for. An indicator using the wrong lookback, a position size off by a factor, a return series that includes the entry bar. The backtest completes, the equity curve looks reasonable, and nothing signals a problem.

Table 1. Failure modes when generating strategy code with an LLM
FailureHow it shows upDanger
Code that does not runAn errorLow — fails loudly
Invented indicator or formulaPlausible name, wrong mathsHigh if unverified against a reference
Off-by-one on barsBacktest completes, uses the current bar's close to trade that barVery high — classic look-ahead, invisible in output
Costs omitted or understatedBacktest completes and flattersHigh — the model defaults to simple assumptions
Shuffled split in the harnessExcellent accuracy that does not transferVery high — standard ML practice applied to a time series
Fabricated citationA real-sounding paper that does not existModerate — check before relying on it
Confident wrong regulatory claimAn invented document number or requirementHigh — verify against the regulator's own site

Rows three and five are the ones to watch, because both produce a working backtest with an inflated result and no error message. Both are also standard machine-learning practice misapplied — shuffling before splitting is correct for independent observations and destructive for time series, which is why a model trained on general ML code reaches for it.

Where an LLM should sit in a live system

The defensible architecture separates proposal from execution. The model researches, explains, writes code and interprets text. Deterministic logic validates every order against position limits, exposure caps, order-rate limits and sanity checks before anything reaches the broker — and that validation does not consult the model.

Two reasons. First, the failure mode of a language model is confident wrongness, which is precisely the failure a risk check exists to catch; a check that asks the model whether the order is sensible inherits the error it is meant to stop. Second, auditability: deterministic constraints are readable code that can be reconstructed after an incident, whereas a model's reasoning cannot be.

This maps onto what the rules already require. Under UK-onshored RTS 6 article 12, firms engaged in algorithmic trading must be able to cancel unexecuted orders immediately, and ASIC's CP 386 proposes an equivalent immediate-suspension control. A stop that depends on a language model responding correctly is not a stop.

Agentic systems

Systems that plan and act over multiple steps toward a goal are an active supervisory topic rather than a settled capability. IOSCO published a report addressing agentic AI in May 2026 — IOSCOPD823, reference FR/02/2026 — following its earlier work on AI in capital markets in IOSCOPD788 of 12 March 2025.

The open questions are governance rather than capability: who is accountable when an agent acts, how it is stopped mid-sequence, how its decisions are reconstructed afterwards, and how a firm demonstrates control over something whose specific actions it did not specify. Those questions sit awkwardly against existing requirements — the annual self-assessment cycle in RTS 6 article 9 assumes a system stable enough to assess once a year.

For an individual, the practical point is narrower. Autonomy multiplies the consequences of every failure mode above. The lower the human involvement, the more the deterministic risk layer has to carry.

Using an LLM well: use it as a critic

The most reliable application inverts the usual one. Instead of asking a model to generate a strategy, ask it to attack one.

  1. "List every way this backtest could be producing an inflated result." Critique of methodology is well covered in training data; the answers are good.
  2. "Check this split for look-ahead bias." Reviewing code for a known bug class is a task models do well.
  3. "Write code that re-runs this with doubled trading costs." Mechanical work, high value, low risk.
  4. "What would have to be true for this strategy to stop working?" Forces articulation of the assumption the strategy rests on.
  5. "Explain this regulatory requirement, and give me the document number." Then verify the number at the regulator's own site — models invent these.

Alongside that, three habits: log every variant including abandoned ones, verify every numerical claim against a reference implementation, and reserve a test period after the model's knowledge cutoff.

Is any of this regulated?

Using a language model to inform your own trading is not a regulated activity in the UK, Australia or New Zealand. The tests turn on whether a computer determines order parameters with limited human intervention, and on whether you provide services to others — not on whether a model was involved. Our page on what regulators mean by "algorithm" works through the definitions.

Two things do change the analysis. Letting the model determine order parameters without human intervention brings the activity within the functional definition of algorithmic trading, which matters if you are an authorised firm. And using model output to advise other people is regulated advice regardless of what generated it.

What we could not establish

  • Any study of LLM-generated strategy performance against a benchmark after costs. Data not found.
  • Any measurement of the training-corpus leakage effect. The mechanism follows from how these models are built; we found no study quantifying its size. Data not found.
  • Adoption figures for LLM use in strategy development. Circulating survey figures come from small self-selected samples. Data not found.

Key takeaways

  • The model removes the typing, not the validation. Writing a backtest was never the bottleneck.
  • The training corpus is a leakage channel that no amount of correct data handling closes.
  • Test after the knowledge cutoff, or forward-test on data that did not exist when you generated the idea.
  • Cheap iteration inflates the trial count and therefore the best result. Log every variant.
  • Silent numerical errors are the real hazard, particularly off-by-one bars and shuffled splits.
  • Keep the model out of the risk layer and use it as a critic instead of an originator.

Frequently asked questions

Can ChatGPT or another LLM build a profitable trading strategy?

It can write strategy code quickly and competently. Whether the result is profitable depends on validation, costs and market conditions — none of which the model can establish. No published evidence shows LLM-generated strategies outperforming a passive benchmark after costs.

What is an LLM actually good at in this context?

Writing and debugging code, explaining unfamiliar concepts, summarising documents, generating test cases, and drafting the boilerplate around a strategy. These are real productivity gains in the parts of the work that are engineering rather than forecasting.

Why is the model's training cutoff a problem for backtesting?

Because the model has read commentary about the period you are backtesting on. A strategy it suggests for 2020 to 2024 may reflect what is widely known to have worked in those years. That is look-ahead bias arriving through the model rather than through your data pipeline, and a clean chronological split does not remove it.

How do I avoid the training-corpus leakage problem?

Reserve a holdout period after the model's knowledge cutoff and test there, or better, forward-test on data that did not exist when the model was trained. If a strategy only works on periods the model could have read about, treat that as a warning rather than a result.

Does an LLM make overfitting better or worse?

Worse, by making iteration nearly free. Testing many variants inflates the best result regardless of whether an edge exists; at a 5% significance threshold, 20 worthless variants give roughly a 64% chance one appears significant. An LLM lets you run hundreds of variants in an afternoon.

Can an LLM hallucinate financial data or indicators?

Yes. Language models can invent plausible-sounding indicators, misstate formulas, cite papers that do not exist and produce code that runs but computes the wrong thing. Silent numerical errors are the dangerous category, because the backtest completes and looks credible.

Should an LLM be allowed to place trades directly?

Generally no. A safer architecture uses the model for research, code and interpretation, with deterministic risk logic independently validating every order against position limits and sanity checks before it reaches the broker. The validation must not consult the model.

Do LLMs understand markets?

They model text about markets, which is a different thing. A model trained on financial writing reproduces the consensus of that writing, including its errors and its survivorship bias toward strategies that worked in the period it was written about.

Is there evidence that LLM-designed strategies work?

No published evidence establishes it. Broader machine-learning evidence is unfavourable: a peer-reviewed review of 27 machine-learning equity experiments found no conclusive evidence of returns at scale, and AI hedge fund indices have underperformed passive benchmarks.

What about agentic AI that trades autonomously?

It is an active supervisory concern rather than a settled capability. IOSCO published a report on agentic AI in May 2026 (IOSCOPD823, FR/02/2026). The governance questions — who is accountable, how it is stopped, how decisions are reconstructed — are not yet answered by the technology.

Is using an LLM for trading regulated?

Using one for your own account is not a regulated activity in the UK, Australia or New Zealand. The regulatory tests turn on whether a computer determines order parameters with limited human intervention, and on whether you provide services to others — not on whether a language model was involved.

What is the most useful way to use an LLM here?

Ask it to attack your strategy rather than build one. Have it list the ways your backtest could be wrong, check your split for leakage, or write the code that stress-tests your cost assumptions. It is more reliable as a critic than as an originator.

About this page

Compiled by AI Trading Book Editorial. The multiple-testing probabilities are elementary arithmetic computed here and labelled as our own, not cited. The training-corpus leakage argument follows from how these models are built and from established definitions of look-ahead bias; we found no study measuring its magnitude and say so rather than implying one exists. Published 27 August 2026; last updated 28 August 2026. Corrections are logged on the corrections page.

Sources

  • Buczynski, Cuzzolin and Sahakian, International Journal of Data Science and Analytics 11(3), April 2021 — review of 27 machine-learning equity experiments; no conclusive evidence of returns at scale.
  • Eurekahedge AI Hedge Fund Index — 9.8% annualised against 13.7% for the S&P 500, December 2009 to July 2024.
  • Harvey, Liu and Zhu, Review of Financial Studies 29(1), January 2016 — recommended t-statistic threshold above 3.0.
  • Bailey and López de Prado — Deflated Sharpe Ratio, 2014; Probability of Backtest Overfitting.
  • arXiv 2407.09831 (preprint) — inflated accuracy attributed to look-ahead bias from shuffled splits.
  • IOSCO — IOSCOPD788, 12 March 2025, on AI in capital markets; IOSCOPD823 (FR/02/2026), May 2026, on agentic AI.
  • UK-onshored MiFID II RTS 6 — article 9 annual self-assessment; article 12 kill functionality.
  • ASIC — CP 386, 27 August 2025 — proposed immediate-suspension control for Trading Algorithms.
  • AI Trading Book calculation — the multiple-testing probability chart (1 − 0.95ⁿ).

Informational research only. Nothing on this page is personal financial, legal, tax or investment advice, or a recommendation to build or deploy any system. Automated trading can lose money rapidly.