The Last Click

Sending orders from a spreadsheet looks like an anti-pattern — RTD exists to stream data into Excel, not out of it. One discipline makes it work: minimize the number of clicks; never zero.

The wrong direction

Everything in this series so far has moved in one direction. Quotes, positions, account values, order status — data flows out of TWS, through the RTD server, into Excel. That's what Real-Time Data is for: Microsoft designed it as a delivery protocol, a way for a server to push values into a spreadsheet without freezing it. Nothing about it suggests traffic going the other way.

This article is about sending order details from the spreadsheet, over a protocol built for streaming data into it. On its face that's an anti-pattern. The first article (Beyond Market Data) promised the one discipline that keeps it safe; this piece is about that discipline.

Why want it at all? Because the trader is already there. A dashboard earns its keep by putting everything relevant to trading on one screen. Turning to another screen to enter trades means looking away from the data that drives it, and the cost compounds. On my desk, manually entering a single order through the TWS interface with the desk's preset variables was typically a ten-click affair. With a typical day seeing upwards of a hundred separate orders, that's thousands of clicks. And since order flow concentrates approaching the market close, every extra click could make the difference between sending a good trade or missing its window.

Read-only by design — and rightly so

With real money on the line, trading requires a careful pipeline with redundant checks and controls to prevent errors. Out of the box, TWS won't even listen: its API defaults to "Read-only," ignoring any messages asking it to configure an order. Users must intentionally flip that switch before they can enter data from outside of Interactive Broker's own order management interface.

My trading workflow had a bottleneck in the order entry stage (recall the ten-click average per order in TWS). Excel offered an interface where I could preset more of what I need in each order. But extending my RTD server in the write direction required me to ensure that all of the controls that apply in TWS would still apply to orders configured from outside of it. The rule I built the entire order path around is easy to state: minimize the number of clicks; but never zero.

A subscription whose side-effect is an order

Mechanically, the trick is that the RTD contract is more permissive than the tutorials suggest. To Excel, an RTD formula is a subscription: a list of string arguments handed to the server, and a promise that values will flow back into the cell. Excel doesn't inspect the arguments or care what the server does with them. So the server is free to interpret them — and mine recognizes StageOrder as the start of an order intent:

=RTD("Tws.Rtd", , "StageOrder", "sym=AAPL", "side=BUY", "shares=100",
     "type=LMT", "limit=150.05", "exch=SMART")

Placing that formula in a cell is what stages the order. Excel sees an ordinary subscription; the RTD server sees an instruction to forward to TWS. And since Excel is listening, the values flowing back into the StageOrder cell can report the order's lifecycle. The cell displays the value Sending when the RTD server picks it up, then Staged once TWS acknowledges receiving it. The order appears in the TWS order list with a Transmit button, and it waits there until a trader clicks the button send it to the market. Because it goes through TWS, an order staged via RTD is subject to the same risk and compliance checks that apply to orders configured directly in TWS.

After the trader transmits an order, the same StageOrder cell in Excel keeps listening, and the RTD server turns to relaying TWS's own status stream: Submitted, Filled, etc. Rejected orders can be corrected like any other in TWS, retransmitted, and the cell follows along.

The write path inherits the transport, the threading, and the logging the read path already earned — the same log that records every market-data subscription records every order intent. What had to be invented was the discipline.

Never zero

Here it is: every order the engine relays to TWS carries transmit=false. Not a default the workbook can override — a constant that nothing in Excel can reach. The order arrives at TWS staged, and the only way it goes to market is a human clicking Transmit in TWS itself.

It's worth being precise about whose choice that is, because it's the heart of the design. This is not an IBKR limitation. Their API will transmit an order directly when asked — unless the user has thrown TWS's read-only switch, the write path runs all the way to the market. The constraint is mine, built in as defense-in-depth. However automated the workbook becomes, the pipeline stops at the same gate: an order detail accepted by TWS and waiting for a deliberate act of human approval.

That's what "minimize the number of clicks; never zero" means in practice. Ten clicks per order was a tax on attention, and the spreadsheet removes nine of them. The tenth is not overhead. The floor is one, and the click at one is the human taking responsibility for the order.

Two boundaries worth clarifying: A staged order lives in TWS, not in the spreadsheet. Delete the StageOrder formula before the order reaches a terminal state and the engine makes a best-effort attempt to cancel the draft, but once it's staged TWS owns it. And nothing bounds how many drafts an over-eager workbook can stage; the bound is that none of them can move. A blotter full of unwanted drafts might be a mess to clean up. But no money moves on it.

The same posture runs underneath, where the trader never looks. An order goes out only under a valid order ID confirmed by TWS in the current session; if the engine can't obtain one, the cell shows an error — Fail Loud, the rule this series keeps returning to — rather than the engine guessing with a stale ID.

Excel is too helpful

One wrinkle deserves its own section, because it's the protocol's helpfulness turning around to bite. Excel deduplicates RTD topics: enter formulas with identical arguments in two cells and Excel treats them as the same subscription — the second cell gets a copy of the first cell's value, and the RTD server is never told. For a quote, that's exactly right; a hundred cells watching the same bid should cost one subscription. For an order it's exactly wrong: two identical StageOrder cells produce one order, the second cell displaying a Staged it did nothing to earn.

And "identical" happens more often than you'd think — buying 100 shares of the same name twice in a session is a perfectly ordinary thing to want. The fix lives in the grammar: an optional client tag — nonce=2, or any string you like — makes the order description unique, so Excel issues a distinct subscription. The tag rides through to TWS as the order reference, so the string typed in the worksheet is visible on the staged order itself. Excel's deduplication can't be turned off; it can only be routed around, deliberately, in the design of the topic language.

What the four parts add up to

The first article opened with a broken contraption and a rebuild; the promise since then has been a spreadsheet you can actually run a trading operation from. Streaming everything the Interactive Brokers RTD sample left out, and failing loud instead of going stale. Reconnecting after every drop without the user having to do anything. Holding Excel to the letter of its own undocumented contract. And now the return path: orders staged out of the same grid the data streams into, behind a gate that is always a human.

Part 1 said the best dashboards put the order ticket one click from the data that drives it. Four articles later, that sentence turns out to be literal. One click — in TWS, on an order the spreadsheet staged — and never zero.

The full topic grammar this series has walked through — market data, accounts, positions, orders, staging — lives in the reference documentation at streamxls.com/docs-reference.