2026-09-02 · Safety

Market Data a Bot May Read and Must Never Act On

Reading market data on a schedule is one of the more obviously useful things a bot can do. Prices, filings dates, earnings calendars, index levels, all published, all structured, all boring to check by hand every morning.

Two things make this category different from every other data source, and both need to be in the charter before the first run rather than added after somebody notices.

The data is delayed and you may not know by how much. And the natural next step, acting on it, is the one thing this setup must never do.

Free market data is delayed, and the delay is not stated where you look

Free quote pages on consumer finance sites are typically delayed relative to the exchange. The exact delay depends on the exchange and the data source, it is stated in the site's own terms and disclosures rather than next to the number, and it is not consistent across every symbol on the same page.

That is fine for what a bot should be doing. It is not fine if anybody treats the number as current.

So the first charter line is about labelling, not about accuracy:

Every price or level in the output must carry the time it was observed and the source it came from. If the source states a delay, state it. Never present a quote as current.

The reason to be strict about this is not pedantry about data quality. It is that a number without a timestamp invites somebody to act on it, and acting is the thing this bot must not enable. A timestamped number carries its own limitation on its face, which is the cheapest possible way to stop somebody treating a fifteen minute old figure as the price they will get.

The never-act boundary, written properly

The boundary line belongs at the top of the charter, before the sources, before the schedule.

Read and summarise only. Never place, modify, or cancel an order. Never move, transfer, or convert money or any other asset. Never sign in to a brokerage or banking account. Never recommend a specific buy or sell. If the output would benefit from an action, describe the action and stop.

Six sentences, and each of them is preventing a different drift. The order sentence is obvious. The transfer sentence catches the adjacent case where somebody wires funds rather than trading. The sign-in sentence prevents the setup that makes the first two possible. The recommendation sentence is the subtle one and the one most likely to be argued about.

Why exclude recommendations. A summary that says "this looks like a good entry point" is doing something categorically different from summarising: it is giving personalised financial advice, generated by a system with no view of your circumstances, obligations, or risk position. That is not a service you want running on a schedule, and in many jurisdictions it is a regulated activity when done for others.

The version that is genuinely useful and stays inside the line: report what happened and what is scheduled. The price moved this much. Earnings are on this date. This filing was published. A person reading that is fully equipped to make their own decision, which is where the decision belongs.

Check the terms of the source you are reading

Financial data sites generally have explicit terms about automated access and redistribution, and they are stricter than the terms on an ordinary web page because the data has commercial value.

This is worth ten minutes before you build anything. The questions are simple.

If a source offers an official feed or API, use it rather than reading the page. It is more stable, the terms are explicit, and it will not break the next time somebody redesigns the site. Reading a rendered page is the fallback for sources with no feed, not the default.

If the terms prohibit what you want to do, that settles it. Find another source rather than proceeding quietly, because the cost of being wrong here is a terms violation attached to your account rather than a broken bot. Financial data providers are also more likely than most publishers to notice and to care, since the data is the product rather than a byproduct of one.

What a useful market bot actually produces

Given the constraints, what is left is more valuable than it sounds.

A morning brief covering a watchlist: observed levels with times, the size and direction of moves, anything scheduled today, and any filing published since the last run. Ten symbols, one page, thirty seconds to read, and it replaces fifteen minutes of tab opening.

A calendar view: earnings dates, ex-dividend dates, index rebalancing, scheduled economic releases. All published, all factual, all tedious to assemble.

A change detector: this company published a filing, this fund changed its stated strategy, this ticker appeared in an index change notice. Not opinions, events. This is the highest value of the three, because scheduled things you can look up and moves you would notice, while a filing published on a Thursday afternoon is exactly the kind of thing that gets missed by a person and never missed by something that checks.

personal-cfo in the catalogue sits in this space for household finances rather than markets, and the boundary in it is the same shape: read, summarise, never move money. market-sizing-worksheet is a different job entirely, business sizing rather than securities, and it is worth knowing the difference because the second one carries none of the regulatory weight of the first.

Do not let it near a brokerage account

The single highest risk configuration in this whole area is a signed in brokerage session on the machine the bot uses.

On this platform the reason is concrete. The shared computer is shared across your account, so signed in sessions, files and command line credentials are shared with every Bot on that account. A brokerage session left signed in is available to every bot you run, not just the one you were thinking about. Do not use separate Bots as a security boundary, because that separation does not exist at the level people assume.

The correct posture is that the bot never signs in to anything financial at all. Public pages, published feeds, official APIs with read only keys where they exist. If you want a portfolio view, the read only bank view piece covers the pattern of doing it deliberately and signing out afterwards rather than leaving a session available indefinitely.

Paper positions are the safe way to test an idea

People build market bots because they want to test a hunch. That is legitimate and there is a way to do it that stays inside the boundary.

Record the idea, in writing, before the outcome is known. What you would have done, at what observed level, at what time, with what exit condition. Then let the bot record what actually happened against that written note.

This gives you the thing you actually wanted, which is evidence about whether your reasoning works, without any of the risk. It also produces something a trading log usually does not: a record written before the fact, which is immune to the memory adjustment that makes everybody's recalled hit rate higher than their real one. Logging paper trades with a written stop covers the mechanics.

The rule that keeps it honest is that the note is immutable. Once written, it is not edited. A paper log you can revise after the fact is a diary of your own cleverness. Put the date and time in the note itself rather than relying on file metadata, which is easy to lose and easier to doubt later.

Handle the numbers carefully in the output

Three small habits that prevent specific errors.

State the window for every change figure. "Up 4%" is meaningless without knowing whether that is a day, a week, or since a level you chose. The bot should always say over what period and from what starting value.

Never compute derived figures the source did not publish, unless the arithmetic is stated in the output. A bot that reports a ratio it calculated, without showing the inputs, has produced a number nobody can check against anything.

And carry the currency and the unit every time. This sounds too obvious to write down until you read a brief covering two listings of the same company on different exchanges and cannot tell which currency the second figure is in. The same applies to whether a figure is in thousands or millions, which sources state once at the top of a table and a summary drops entirely.

Symbols are not as unambiguous as they look

A practical failure that has nothing to do with regulation and everything to do with getting the wrong company.

Ticker symbols are reused across exchanges. The same three letters can be one company in New York and a different one in London or Toronto. Companies with dual listings trade under different symbols in different currencies. Symbols change after a rename, a merger, or a reverse split, and the old one is sometimes reassigned to something else entirely.

A person searching notices, because the company name on the page is not the one they expected. A bot following a symbol in a charter does not, and it will report on the wrong company confidently for as long as nobody checks.

The fix is to write the identity into the charter rather than the symbol alone: the full company name, the exchange, and the currency, with the symbol as one field among several. Then have the bot state the company name it actually found in every output, so a mismatch is visible in one line rather than discoverable only by suspicion.

For anything where the identity really matters, use a stable identifier the source publishes rather than the ticker. Tickers are display labels. They were never meant to be primary keys and they do not behave like them.

Decide what the brief does on a day when nothing happened

Most mornings, nothing meaningful moved. What the bot does on those mornings determines whether anybody reads it in three months.

The wrong answer is to fill the space. A brief that manufactures significance from a half percent move trains its reader to skim, and a reader who skims will skim the morning something did happen. The volume of output should track the volume of events, not the schedule.

If nothing in the watchlist moved beyond the stated threshold and nothing is scheduled, say so in one line and stop. Do not expand small movements into commentary to fill the brief.

The one line matters. Silence is ambiguous, because a brief that does not arrive could mean nothing happened or could mean the routine failed, and those need different responses. A short "nothing beyond threshold, next scheduled event is on this date" is unambiguous and takes two seconds to read.

Set the threshold from each symbol's own behaviour rather than one number across the watchlist. A percentage that is remarkable for a large index is routine for a small cap, and a single threshold will either bury the first or spam you with the second.

Who else reads it changes what it is

A market brief that stays in your own document is a private note. The same brief sent to three colleagues is something else, and the difference is worth thinking about before you add the recipients.

Two things change. Redistribution terms may apply, because many financial data sources permit personal use and restrict passing the data on, and a brief circulated internally is a form of passing it on. And the never-recommend rule gets more load bearing, because a factual summary that reaches other people, on a schedule, from a source they trust, starts to function as guidance whether or not it is phrased as guidance.

That second effect is subtle and real. Selection is a form of recommendation. A brief covering ten symbols out of a possible thousand is telling its readers which ten matter, and if the selection changes week to week in response to what moved, it is telling them something stronger than that.

Two habits keep it honest. Fix the watchlist and change it deliberately rather than dynamically, so the selection is a decision somebody made rather than an emergent property of price movement. And state at the top what the brief is and is not: observed data, on a stated schedule, not advice, with the source and delay named.

If the brief is going to more than a handful of people, or to anyone outside your organisation, stop and get advice about what you are doing. Distributing market commentary to others is a different activity from reading data yourself, and the line between them is not where most people assume.

Answer the objection that a delayed brief is useless

The fair objection: if the data is delayed and the bot cannot recommend anything, a market brief is a slower version of opening a page.

For a trader, correct, and this whole category is not aimed at them. Anybody making intraday decisions needs a real time feed with an explicit data agreement, and no part of this article applies to them.

For everybody else, delay is irrelevant. Somebody tracking ten positions they hold for years does not care whether the level is fifteen minutes old. Someone watching a sector for a quarterly review does not care. Somebody preparing for a meeting about a competitor's results does not care. The value is in the assembly, the calendar, and the change detection, none of which are time sensitive.

The version of this that is genuinely not worth building is the one where somebody wants near real time data and near real time decisions. That person should buy a proper data subscription and use software designed for it, and should not be reading a bot's summary of a delayed consumer page under any circumstances.

Common questions

Can the bot read a brokerage portfolio page?

Technically it may be able to, and the reason not to is that it requires a signed in session on a shared computer. Signed in sessions, files and command line credentials are shared with every Bot on that account, so a brokerage session becomes available to everything you run. If you need a portfolio view, do it deliberately in a session you close afterwards rather than leaving one available to a scheduled process.

Is it okay for the bot to tell me a stock looks cheap?

No, and the reason is not squeamishness. That is a personalised recommendation from a system that knows nothing about your position, obligations, or timeline, and it is a regulated activity in many places when provided to others. Have it report facts with sources and make the judgement yourself.

What about crypto?

Same boundary, more emphasis. The read is fine, the never-transact line is identical, and the additional risk is that transactions are irreversible in a way that a mistaken equity order is not. Do not put a wallet or an exchange session anywhere the bot can reach.

How do I handle the delay in a brief that mixes sources?

Label each figure with its own source and observation time rather than putting one disclaimer at the top. Different sources have different delays, and a single blanket statement will be wrong for at least one line. Per-line labelling is slightly uglier and it is the only version that is accurate.

When this page stops applying

Grok Bot is in beta and its mechanics will change. Site terms change too, more often than the platform does, so treat any conclusion you reach about a specific source as dated and re-check it before relying on it in something that matters.

What will not change is the two-part shape: market data is delayed unless you have paid for it not to be, and the gap between reading and acting is a boundary worth defending even when crossing it would be easy. Bots for finance covers the wider set of finance workflows, and the never-pay and never-move-money boundaries there are the same idea applied to a different set of buttons.