Account

Data & credits

Two practical questions come up in every research session: what data am I running on? and what does this run cost me? The Data section answers the first; the credit estimates answer the second. Here's how to read both.

The data on the platform

The Data section lists every dataset available to your runs, with its symbols, date coverage and provenance. Two kinds of data exist:

• Synthetic data — artificially generated market data (a demo instrument with realistic bars, volume and order-flow) used for onboarding, demos and tests. It photographs like the real thing and exercises every feature of the platform, but it carries no information about any real market. Its labeling always says so.
• Licensed market data — real futures data across the CME group — equity indices, energy, metals, FX and rates, sourced on demand from Databento, with per-day coverage tracking. Each dataset's coverage calendar marks days as present, partial, missing, expected, holiday or quarantined (roll boundaries) — so you can see at a glance whether your intended backtest window is fully covered before you launch. When a launch names several instruments, the calendar and the "Data available" line describe all of them together: a day counts only when every picked instrument holds it, the same rule the launch gate applies.

Requesting new data on demand

When you need a range that isn't on the platform yet, ask for it. The Data section opens on Available data — every instrument and data type the platform holds, counted in trading sessions, with a separate count for what a backtest can read today. Under it is the request form: an instrument, a data type, and a date range. That is the whole of it. Filing a request costs nothing and cannot spend anything.

If the platform already has what you asked for, nobody has to approve anything. The request is measured against real exchange sessions the moment you file it, and one that is already covered is granted on the spot with nothing bought — including when the sessions are mid-download for somebody else's request, in which case yours simply rides that delivery. Only genuinely missing sessions reach an administrator.

Your request then moves through two words that mean different things. Arrived means the data is on the platform. Ready to run means the engine catalog behind it is built and a backtest can actually read it. They are minutes apart and we say which one you are in, because "your data is here" and "your backtest will work" are not the same sentence.

Nothing else about the platform's data machinery is on your page. The file registry, the download queue, the platform's spend position and its licensing grants are administrator surfaces — they are how the platform is run, not something a member needs to read to do research.

Behind the scenes, an administrator approving requests works from the same quote-first workflow, and nothing is charged until they approve:

1. Describe the range. Pick the dataset, the symbols, the start and end dates, and the schema:
   • tbbo — top-of-book (L1) quotes and trades; the everyday choice. It is also the priciest per gigabyte, so a single request is capped at 400 days — a full year fits, and anything longer splits into requests you approve separately.
   • mbp-10 — L2 order-book depth, ten levels each side. This is the heaviest schema, so a single request is capped at 31 days — narrow the window or split it.
   • definition — instrument reference data: the contract specifications (tick size, expiry, exchange) the engine loads before any price data. Buy it for the same instruments and window as your tick data. Without it the ticks download fine but nothing can be run over them, because the engine has no contract to attach them to. The app adds it to your request automatically, and it is a few hundred kilobytes.
2. Get a free quote. The request returns the exact cost and any degraded days, and it expires after a day so a stale quote never gets approved. Requesting a quote never spends.
3. A human approves. Approval names the cost out loud (you type it to confirm) and must acknowledge every degraded day — each one enumerated, each one on the record. There is a select all control, because approving twenty days one click at a time is not a safety feature; what it is not is a blanket flag, and the days it ticks are still sent individually and still travel with the data afterwards. The days are grouped by the request they belong to, each group headed by the plain-English schema name, the symbols and the window, so a large bundle reads as a short list rather than a wall; and the Approve bar stays pinned to the bottom of the dialog however long that list is, with the button telling you which of the two conditions — every day acknowledged, and the typed cost — is still holding it back. If a window is out of coverage or has degraded availability days, the app says so in plain words before anything is approved. Delivery is then integrity-checked before the data is usable.
4. The acknowledgment stays with the data. Days you accepted as degraded are marked on the coverage record itself, not just on the approval: the coverage strip rings them and names the provider's condition, and the launch dialog warns you before a backtest runs over one. A result is never presented as sound when the platform already knows the sessions behind it were degraded when they were bought.

Two questions, two answers. "Last 12 months" means something different depending on which screen you are on, and both are deliberate. On a launch screen it means the last twelve months of data already downloaded and prepared, because a backtest can only read what is on the platform — so the window stops at your newest usable session. On the data-request screen it means the last twelve months up to yesterday, whether or not any of it has been bought, because that screen exists to buy what is missing. Both count real exchange sessions from the trading calendar, so a holiday is never reported as a missing day. The request screen names what it anchored on, how much of the range you already hold, and how much a quote would cover.

Every request shows its progress on a status timeline — from quoted through approved, delivering and verifying to complete — and a request that hasn't yet been submitted to the provider can be stopped or cancelled with nothing spent. Once the order reaches the provider, the money is committed and the download runs to completion (or a named failure). A failed download carries a one-click Retry that re-runs it under the original approval — no new spend authorization, and an already-billed batch re-downloads free inside the provider's window.

You can bill a fetch to the platform budget (an admin approves) or to your own vendor account via a connection you configure, in which case you approve your own spend.

Data watches — standing gap detection, never standing spend

Coverage can also be watched instead of checked by hand. A data watch is a standing rule — instrument, schema, window — that the platform re-checks on a schedule (or on demand with Run now) and reports any gaps it finds. Watches are detection-only by design: a watch can tell you data is missing, but it can never buy anything — every actual purchase still goes through the same quote-first, typed-approval flow above. A watch that finds a gap files a pre-quoted request and notifies the admins (nothing is spent); watches themselves are managed by admins in Admin → Data Acquisition.

Bring your own data

You can also skip the vendor entirely and upload data you already have, from the Data section's Datasets tab:

• CSV — OHLCV bars, trades, or L1 quotes, for futures, equities or FX (you name the symbol and, for CSV, the asset class and optional venue).
• Databento DBN — a raw DBN file (including the compressed .dbn.zst form).

An upload is validated by the engine and written once into an isolated catalog that only you can read, ready to backtest against. Uploading calls no vendor and spends nothing — but you are responsible for the data's licensing. Behind the scenes each dataset (platform or BYO) is compiled into a fast catalog the backtest reads; depth uploads build an L2 catalog, quotes/trades an L1 one, and rebuilding identical inputs is a no-op.

That compile step is why “downloaded” and “runnable” are two different things. Bytes register the moment a download finishes, and the Data page shows them straight away; a backtest reads the catalog built from them afterwards. If coverage shows days as delivered but not runnable, that build is what is outstanding — most often because the matching definition data has not been bought yet, or because the built catalog on disk changed and the platform is rebuilding it (each built catalog carries its build’s stamp, and days are only offered while the live catalog still carries the stamp of the build that made them — so what the launch screen offers is always what a run can actually read). An administrator sees the exact reason, and what to do about it, in Admin → Data Acquisition under “Catalog builds needing attention”, where every stuck build carries a Retry build control once its cause has been fixed.

Re-downloading data never fixes a failed build. Deliveries are deduplicated by content, so asking for the same window again returns the same files the platform already holds — the build's inputs do not change and nothing restarts. It also spends your plan's data allowance for nothing. Fix the cause the build names, then press Retry.

What consumes credits

Credits meter the platform resources your research consumes. The rules of thumb:

• Always free: running tests and previews. The cheap loop — edit, test, preview — never costs credits, so there is never a reason to skip testing.
• Metered: full backtests and notebook runs (by compute time), AI-builder usage, data scanned by runs, artifact storage, and generated report bundles. AI usage also runs under daily call and token quotas set by your plan — see Pricing for the exact numbers per tier.
• Your account has a monthly included allowance; if a launch would exceed your balance, the app refuses it with the exact shortfall and what to do about it (an admin top-up — or keep working in the always-free tier).

Reading the estimate

Before a metered run launches, the dialog shows Estimated cost (credits), e.g.:

• sandbox-min — estimated minutes of isolated compute; this is what actually drives the credit figure for runs.
• cpu-s — estimated processor seconds, a finer-grained signal of how heavy the run is.
• basis / n — where the estimate came from: it is calibrated from a sample of comparable past runs. A small n means a rougher estimate.
• The caveat is honest by design. Estimates come with a plain statement that credit cost bases are provisional and recalibrated against real usage. Your balance is always exact; the forecast of what a run will consume is an estimate and is labeled as one.

Platform spend caps

Separately from your credits, the platform's own spending (for example on data acquisition) runs under hard monthly and per-request caps. Those caps and the platform's position against them — month-to-date used, in-flight, remaining — are administrator-only: they are the platform's finances, not yours, and they are not served to a member's page at all. The cap is enforced server-side, so the platform refuses to exceed it rather than warning after the fact.

Nothing on your Data page can spend money by itself, or ask anyone else to. You file a request; an administrator decides; only the sessions the platform does not already hold are ever bought, and they are quoted first from free provider metadata.

The same day is never bought twice. Approving a request reserves each missing session exclusively before anything is ordered, so two administrators working the queue at the same time cannot both buy an overlapping range — and a request whose days are already reserved by an earlier approval is attached to that purchase instead of triggering a second one.