Article
How to Legally Display IBKR Market Data Without Becoming a Data Vendor
The rule that decides your whole architecture: the moment market data flows through infrastructure you operate, exchanges treat you as a redistributor. Here is how to avoid that.
If you are building anything that shows Interactive Brokers price data to users, one rule governs your entire design: exchanges license their market data, and the moment that data flows from a server you operate to your users, they consider you a data vendor or redistributor — which triggers licenses, per-exchange agreements, fees, and audits. This is a plain-language walkthrough of that rule and the one architecture that sidesteps it. It is based on our own experience building MyLinedChart, is educational, and is not legal advice — verify current terms directly with IBKR and the relevant exchanges before you build.
The Rule That Decides Everything
Exchanges like NYSE and Nasdaq treat their price data as a licensed product. The line that matters is redistribution: the moment market data flows from infrastructure you operate out to your users, you look like a data vendor in the exchanges' eyes. That status brings licenses, per-exchange agreements, ongoing fees, and audits.
The crucial and counterintuitive part: it does not matter that the data originally came from IBKR. If it passes through a server you run on its way to a user, you are the one redistributing it. The source is not the trigger — your infrastructure carrying it is.
- Market data is licensed, not free to relay.
- Redistribution = serving it from your infrastructure to users.
- Coming from IBKR does not exempt you.
Why the Hosted / Cloud Path Stalls
The instinct is to build it like normal SaaS: a backend pulls data through IBKR's Web API and streams charts to a browser. Going that route through IBKR's third-party program means a Web API integration fee (roughly $60k, structured as three $20k stages) — and, separately and on top of it, exchange market-data licenses. Per IBKR, the Web API will not let you display market data outside IBKR's own platforms without those exchange licenses, even when the end user has their own market-data subscription.
There are prerequisites too: a registered company with a physical location, a complete live website, and roughly 250 active users before you can even apply, then a 3–4 month review. For a pre-revenue product, that is a large upfront cost and a compliance burden to carry before you have users. It is a deliberate path to take with capital, not a default. (For the cost specifics, see The IBKR Market-Data License Costs Nobody Warns Builders About.)
- ~$60k IBKR Web API integration fee (three $20k stages).
- Exchange market-data licenses on top — a separate, additional cost.
- 250-active-user gate plus a 3–4 month approval before launch.
The Local Architecture That Sidesteps It
The alternative: each user runs the app on their own machine, connected to their own IBKR account through their own IBKR connection (TWS, Gateway, or a local connector). Market data flows from IBKR straight to the user's own machine, under the user's own market-data subscriptions. You, the developer, never receive, store, or relay the data.
Because the data never touches your servers, you are not redistributing it. There is no exchange license to buy, no per-exchange fee, no vendor gate, no audit — the user is already licensed for their own data through their own IBKR subscriptions, and your software is just a chart on top of a connection they already have. The compliance problem does not get paid down; it disappears.
- Data path: IBKR -> the user's own machine, never your server.
- The user's own subscriptions cover the data.
- No redistribution, so no license, fee, gate, or audit.
What This Forces About Your Product
This one constraint shapes everything downstream. It has to be a desktop or local app, not a website, because the data must stay on the user's machine. It is single-account by nature — the user's own IBKR session — with no multi-tenant server pooling data. And your differentiation moves to what you can do locally rather than to a cloud data feed.
That is exactly the road MyLinedChart took, and it is why the product is a local app with an AI/MCP write channel rather than a hosted charting site. For the architecture in detail, see Build a Local IBKR + AI Chart App: The MCP and Connector Pattern; for the cloud-versus-local trade-off, see Why Your IBKR Trading App Should Be Local, Not Cloud. If you would rather not build it yourself, workflow consulting covers the same workflow decisions.
FAQ
Does getting data from IBKR make it legal to show to my users?
Not by itself. The trigger is redistribution — serving the data from your infrastructure to users. If it flows through your server, you are likely a redistributor regardless of the source. This is educational, not legal advice; confirm with IBKR and the exchanges.
How does a local app avoid the redistribution problem?
The data flows from IBKR to the user's own machine under the user's own market-data subscriptions. You never receive or relay it, so you are not redistributing anything.
Can I ever build the hosted/cloud version?
Yes, deliberately and with capital — by acquiring the exchange market-data licenses and accepting the fees and vendor commitments. It is a scale decision, not a default starting point.
Sample Structured Chart-Data Exports
Review how chart drawings, annotations, OHLC, volume, and execution context become reusable structured data.

