> ## Content Index > Fetch the complete content index at: https://www.etrminsider.com/llms.txt > Use this file to discover other available public pages before exploring further. # Where AI actually helps on a trading desk today (and where it doesn't) - URL: https://www.etrminsider.com/where-ai-helps-on-a-trading-desk/ - Published: 2026-10-14T11:02:55.000Z - Updated: 2026-10-14T14:02:56.000Z - Description: Three bins for AI on a trading desk: working now, promising but needs controls, and not yet. For each use case: the data it needs, the control it needs, and how it fails. - Author: Emmanuel Gonzalez - Tags: AI in Energy **Independence:** ETRM Insider is vendor-independent. This article names no preferred products, and no vendor sponsored, paid for, or reviewed it. [Our standards →](https://www.etrminsider.com/standards/) Every trading organization I talk to has been asked some version of "What's our AI plan?" The honest answer is usually smaller than the slide. That's fine. Small, controlled uses that save real hours beat a pilot that never touches production. I sort use cases into three bins. For each one I ask three questions: what data does it need, what control does it need, and how does it fail? If you can't answer all three, it's not a use case yet. It's a demo. ## Bin 1: Working now These are tasks where a person stays in the loop, the output is easy to check, and a mistake is caught before it costs money. **Contract and confirmation term extraction** - *Data:* the documents themselves (master agreements, confirmations, PPAs) and the trade record you're checking them against. - *Control:* the model proposes fields, a person approves them, and the system compares extracted terms to the booked trade and flags differences. - *Failure mode:* confident extraction of the wrong field, like a delivery point from the wrong annex or a price from an example table. The compare step is what catches it, so never skip it. **Settlement exception triage** - *Data:* the breaks themselves, with invoice lines, trade data, volumes, prices, and the history of how similar breaks were resolved. - *Control:* the model sorts and explains. It suggests a likely cause and a next step, and a person decides. Nothing posts automatically. - *Failure mode:* the model learns your old workarounds and recommends them. If past resolutions were "adjust and move on," it'll suggest the same. **Report narratives** - *Data:* the numbers that already exist: the P&L explain, position changes, the risk report. - *Control:* the narrative is generated only from the report's own figures, and every number in the text is checked against the source table before it goes out. - *Failure mode:* a sentence that sounds right but cites a number that isn't in the report, or explains a move with a cause nobody verified. **Code and query assistance** - *Data:* your schema documentation and examples of correct queries. Without them, the model guesses table names. - *Control:* normal code review, test data, and read-only access for anything generated against production. - *Failure mode:* a query that runs, returns plausible numbers, and is quietly wrong because it joined on the wrong key or missed amended trades. What these have in common: the human is checking, not trusting, and the check is cheaper than doing the work from scratch. ## Bin 2: Promising, but needs controls first These can work. They need tighter data and governance than most shops have today. **Curve quality checks** - *Data:* daily curve history, source quotes, and a record of past manual overrides and why they were made. - *Control:* the model flags unusual moves or shapes for a person to review. It doesn't change a curve. Flags and their dispositions are logged. - *Failure mode:* false positives on volatile days train people to ignore the flags. Then the one real error slips through. Tune it, and track how often flags turn out to matter. **Anomaly flags on positions and P&L** - *Data:* clean position history by book and product, and a reliable P&L explain. If the explain doesn't tie out, the model is learning noise. - *Control:* flags go to the risk team as a review queue, with thresholds the risk committee approves. - *Failure mode:* the model treats a known, legitimate change (a new structured deal, a book transfer) as an anomaly, or misses a slow build because it looks normal day to day. The common requirement here is history you trust. If your data has gaps or unexplained manual adjustments, fix that first. That's the subject of a later article on AI readiness. ## Bin 3: Not yet I'd say no to these today, and I'd say it plainly in the steering committee. **Autonomous trading decisions** - *Why not:* accountability. Someone has to own every position, explain it to risk, and answer for it if it goes wrong. A model can support a trader's analysis. It can't hold the limit. - *Failure mode:* the model does something reasonable on average and disastrous in a market it has never seen. **Unsupervised valuation** - *Why not:* valuation numbers flow into financial statements, margin, and risk limits. They need a documented method, independent price verification, and a person who can defend them to auditors. - *Failure mode:* a mark that can't be explained. "The model said so" is not an answer your auditors will accept. "Not yet" isn't "never." It means the controls, the accountability model, and the data aren't there, and pretending otherwise is how a pilot turns into an incident. ## A quick test for any proposed use case Before anything gets a budget, I'd want a one-page answer to these: 1. What decision or task does this support, and who owns it today? 2. What data does it need, where does that data come from, and who vouches for its quality? 3. How will a person check the output, and how long does that check take compared to doing the task by hand? 4. What happens when it's wrong? Who notices, and how fast? 5. What gets logged, so you can explain later what the model saw and what it produced? 6. What does success look like in hours saved or errors caught, measured against a baseline you recorded before you started? If the answer to question 3 is "nobody checks," move the use case down a bin. ## Use it this week List every AI idea your team has floated. Put each in one of the three bins, and write the data, control, and failure mode next to it. The ones in Bin 1 with a clear check step are your pilots. The rest go on the list for after the data work. --- *Drafted with AI assistance from my research notes and outline; reviewed, edited, and fact-checked by me. The opinions are mine.*