Start with what you are building
The right provider depends on the job. A trading terminal needs two-sided quotes on every instrument a client can trade, real-time delivery and a history deep enough for the charts. A prop-firm dashboard needs reliable prices for evaluation rules and clear records of when a price arrived. A financial website needs readable prices and display rights for public pages, and can often live with delayed exchange data.
Write down three things before you talk to anyone: the instruments you must have on day one, the screens where prices will appear, and who will see them (your staff, your clients or the public). Every item on the checklist below is easier to judge against that list.
Coverage and normalization
Coverage is not a number of symbols. It is whether the instruments your clients ask for are present, quoted during the hours they trade, and named in a way your system can map. Ask for the instrument catalogue and match it against your own list line by line.
Normalization matters as much as coverage. When data arrives from several sources, a good provider delivers it in one format: the same symbol conventions, the same field names, the same timestamp rules and a known number of decimal places per instrument. Without it, your team writes one adapter per asset class and maintains it forever.
- Is there a machine-readable catalogue with symbol, name, asset class and precision?
- Do symbols stay stable, and how are you told when one is added or retired?
- Are all timestamps in UTC, and are exchange sessions handled on the provider side?
Bid/ask or last price
Check what kind of price each asset class carries. Where a market is two-sided, such as forex, spot metals and US stocks, a broker needs bid and ask, because that is what a client trades against and what the spread is built from. On other markets a single last price is the natural representation: crypto trades on many venues, an index is a calculated level, and commodities and bonds are usually shown by a reference price.
Ask the provider to state this per asset class, not in general. A feed that fills bid and ask with the same last price is fine for display, as long as you know it and do not show a spread of zero. The bid, ask and spread guide covers the details.
Latency and real-time vs delayed
Two questions hide behind the word latency. The first is how fast a price reaches you after the provider receives it; for a streaming feed this should be well under a second. The second is whether the data is real time at all: exchange data is often distributed with a delay of around 15 minutes unless you have the right to show it live.
Make the provider list, per asset class, what is real time and what is delayed, and how the delay is marked in the data. Also separate data latency from refresh rate: a widget that redraws every few seconds is a display choice, not a delay. See real-time vs delayed market data.
History and timeframes
Charts and analytics need candles, and the depth of history differs by timeframe. Daily candles usually go back years, intraday candles only months. Ask for the exact depth per timeframe and check that it covers the charts your clients open most.
Ask how candles are built: from which price series, on which base timeframe, in which time zone, and whether stock candles follow exchange sessions. Live candles that you build on your side must follow the same rule, otherwise the last bar jumps when it is replaced by the stored one. More in how candles are built from ticks.
Delivery protocols
Most platforms need both a stream and request-response access. WebSocket suits live prices: one connection, prices pushed as they change. REST suits history, the instrument catalogue and occasional lookups. A provider that offers only polling over REST will cost you either freshness or rate limits.
Read the documentation before the sales call. Check the message format, how subscriptions work, how a reconnect restores state, and what the rate limits are. The WebSocket vs REST guide explains the trade-offs.
Fallback and monitoring
Every source fails sometimes. The question is what happens next. A provider with redundant sources switches an asset class to another source automatically; a provider with one source per market goes silent with it.
Ask how they detect problems. Uptime of the service is not enough: a connection can be up while one instrument has stopped updating. Monitoring of silence per instrument, alerts and a public description of the reliability setup are good signs. Ask for the uptime target and how incidents are communicated.
Authentication and keys
Check how access is protected. Signed authentication, for example with HMAC, keeps the secret off the wire. Ask how keys are issued, rotated and revoked, whether you can have separate keys for test and production, and what happens to open connections when a key is revoked.
Never place a feed key in front-end code. Connect from your server and pass prices to your clients from there.
Licensing and display rights
Market data comes with usage terms. They can depend on who sees the data (internal staff, your clients, the public), on whether it is real time or delayed, and on whether you redistribute it. The terms differ between exchanges and change over time.
This guide does not give legal advice. Ask the provider in writing what your planned use allows, read their market data policy, and check the result with your own lawyer before you go live.
Support and SLA
When prices stop at 03:00 UTC, you need someone who answers. Ask who handles incidents, how to reach them, how fast they respond, and whether the commitments are written in the contract. A named engineering contact during integration saves weeks.
Price and pricing model
Market data pricing usually depends on the instrument set, the asset classes, real-time or delayed use and the number of users or screens. Compare offers on the same basis, and ask what changes the price: adding an asset class, more users, or public display.
Watch for per-request or per-message billing on the stream. It makes costs hard to predict, because they grow with market activity rather than with your business.
How to run a pilot
A short pilot answers more than any presentation. A practical plan:
- Agree on the instrument list and success criteria in advance: coverage, update frequency during busy hours, gaps, reconnect behaviour.
- Connect from a test server, subscribe to your real list and record every tick with its arrival time for at least a few trading days, including a market open.
- Load history for the same instruments and compare the last candles with the ones you built from the live stream.
- Break the connection on purpose and check how fast prices resume and whether anything is lost.
- Open a support question and measure the reply time.
Questions to ask a provider
Use this table in the first call. The second column shows how to read the answer.
| Question | What the answer tells you |
|---|---|
| Which asset classes carry bid/ask and which carry last price? | A clear per-class answer means they know their data. A vague one means you will find out in production. |
| What is real time and what is delayed, per asset class? | Tells you what you can show live and where you need delay labels. |
| How many independent sources per asset class, and is fallback automatic? | One source per market means its outages become yours. |
| How do you detect an instrument that stopped updating? | Per-instrument silence monitoring catches problems that connection checks miss. |
| How deep is history per timeframe, and in which time zone? | Shows whether your charts will have enough data and whether you need time-zone conversion. |
| What are the rate limits, and is there per-message billing? | Predictable limits and no per-message charges keep costs and load planning simple. |
| What does our planned use allow on public pages? | A written answer is the starting point for your own legal check. |
| Who answers incidents, and how fast? | Tells you whether support exists outside business hours. |
How it works at FinaQuotes
FinaQuotes is market data infrastructure, not a broker or a liquidity provider. Data is aggregated from multiple institutional and exchange data sources and normalized by FinaQuotes into one format across seven asset classes. Here is how it answers the checklist:
- Two-sided bid/ask on forex, spot metals and US stocks; last price on crypto, indices, commodities and bonds. See coverage.
- US stocks in real time with trades and quotes; non-US stocks delayed by about 15 minutes; other asset classes in real time. Ticks are delivered sub-second after receipt.
- Candles on 9 timeframes from 1 minute to 1 month, built from a 1-minute base, in UTC, with stock candles following exchange hours. Years of daily history, months of intraday. See historical data.
- WebSocket stream with HMAC authentication and no per-message billing; REST for history, the instrument catalogue and logos, with a default limit of 120 requests per minute per IP. See the documentation.
- Several independent sources per asset class with automatic fallback, silence monitoring per instrument and alerts, with a 99.9% uptime target. See reliability.
- Access by request; we reply within one business day. Pricing is quoted per project, see pricing and market data for brokers.
Frequently asked questions
What matters most when a broker chooses a market data provider?
For a broker, the essentials are two-sided bid/ask on tradable markets, real-time delivery, automatic fallback between sources and clear display rights. Coverage and price matter too, but a feed that goes silent or shows the wrong price type costs more than any discount saves.
Is a market data provider the same as a liquidity provider?
No. A market data provider delivers prices for display, charts and monitoring; a liquidity provider executes trades. FinaQuotes is a market data provider only and does not execute orders.
How long should a pilot last?
A pilot should cover at least a few full trading days, including market opens and a busy session, so that you see the feed under load. Agree on success criteria before it starts, otherwise the result is a matter of opinion.
Need the feed behind these guides?
Tell us what you are building and which asset classes you need. We reply within one business day with access details and pricing.