Large language models in trading: where they help and where they are a liability

The question we get is “can an LLM trade for me”. The answer is that it can, badly, and that there are three places in a trading operation where the same technology is genuinely useful.

Why not in the decision path

Four properties make an LLM a poor fit for the thing that emits orders:

• Non-determinism. The same input can produce different output. A backtest of a non-deterministic decision function does not describe the thing that will run.
• Latency in the hundreds of milliseconds. Fine for a report, disqualifying for anything reacting to a book event.
• No calibrated confidence. The model produces fluent text at the same confidence whether it is right or wrong. Position sizing needs a number that means something.
• Unbounded input surface. If any part of the input comes from outside your systems — a news feed, a social post — that text is now an instruction channel into your trading logic.

Where it genuinely earns its place

1. Turning text into structure. This is the real use case. Given an exchange announcement, extract: instrument, event type, effective time, whether trading is affected. The output is a typed record, validated against a schema, which then feeds ordinary deterministic logic.

# The model produces data. Rules decide. Never the other way round.
class VenueNotice(BaseModel):
    symbol: str
    kind: Literal["listing", "delisting", "maintenance", "param_change", "other"]
    effective_at: datetime
    halts_trading: bool

notice = extract(llm_output, VenueNotice)     # schema violation -> discard, alert
if notice.halts_trading and notice.symbol in universe:
    risk.blacklist(notice.symbol, until=notice.effective_at + timedelta(hours=2))

Note what this does not do: it does not let the model decide to trade. It lets the model read a paragraph and fill in five fields, which is a task it is actually good at.

2. Research tooling. Writing feature code, generating test cases, explaining an unfamiliar API. Every output is reviewed by a human and validated by tests, so the failure mode is wasted time rather than lost money.

3. Operational triage. Summarising an overnight log, clustering error patterns, drafting an incident note. Read-only, out of the hot path, and a wrong answer is embarrassing rather than expensive.

The sentiment trap

“Score the sentiment of crypto Twitter and trade it” is the most requested LLM strategy and among the weakest. The problems compound:

1. Sentiment is largely a function of price. You are building an expensive, lagged price indicator.
2. The text is adversarial. People post to move markets, and a strategy known to read text is a strategy that can be fed.
3. It is crowded. Every desk has tried this; whatever signal existed is largely priced.
4. It is unbackestable at scale. Historical social data at the resolution you need is expensive and survivorship-biased.

None of that makes text useless. It means the usable part is structured, verifiable events — a delisting, a halt, a parameter change — not diffuse mood.

If you insist on text in the loop

Three constraints make it survivable, and we apply all three:

• The model output is a typed record validated against a schema. Anything that fails validation is discarded, not interpreted.
• It can only ever reduce risk — blacklist a symbol, halt trading, widen a stop. Never open a position.
• Every call is logged with input, output and model version, so a bad decision can be reconstructed.

Under those constraints an LLM becomes a useful sensor. Without them it is an unauditable actor with access to your API keys, and no amount of model quality makes that a good architecture.