A financial data vendor is an organisation that supplies financial datasets, often with collection, standardisation, identifiers, analytics or delivery services. It may originate information, redistribute a publisher's feed, or combine several sources. For a quant, the useful purchase is a documented input to a research or trading process: the data must describe the intended instruments, arrive in time and permit the intended use.
The vendor and the original source need not be the same organisation. An exchange may publish trades, a company may file accounts, and a vendor may normalise those records into a common format. That processing can save substantial integration work. It also means the researcher needs to understand the path from the original observation to the delivered field.
Compare like with like
Consider two fictional feeds covering the same 100 instruments. Each snapshot contains exactly one row per instrument, with no missing or duplicate keys. Feed A supplies three dated snapshots; Feed B supplies two. The deliveries therefore contain 300 rows and 200 rows, respectively.
That comparison establishes a difference in temporal coverage under these conventions. It does not establish that A has more instruments, cleaner values, better point-in-time data, or broader licence rights. Repeated observations of an instrument are not automatically independent evidence. A larger download can also contain duplicates or repeated corrections; those are different objects from the complete snapshots stipulated here.
Original synthetic comparison: complete snapshots of the same instrument universe, before quality checks. The timing example uses one fictional day in UTC and assumes receipt is required for use.
The lower panel asks a separate question. On a fictional day, a release occurs at 09:00 UTC, the strategy decides at 09:01, and its system receives the release at 09:02. The release is public before the decision but unavailable to this strategy at that decision. Required parsing and validation could make usable time later still. Replacing receipt time with publication time would introduce look-ahead bias into a replay of that system.
What to request in a sample delivery
Start with the intended decision: instruments, fields, historical period, frequency and deadline. Then compare the provider's documentation with actual sample records.
| Dimension | Evidence to examine |
|---|---|
| Source and transformations | Original publisher, field definitions, units, currency, aggregation rules and any vendor estimates or calculated fields. |
| Coverage | Historical instrument membership, inactive and delisted names, venues, dates, missingness and the difference between no observation and a genuine zero. |
| Timing | Meaning of each timestamp, timezone, delays, and the clock governing historical queries and live delivery. |
| Versions and corrections | Original releases, correction identifiers, when each version became available, and whether a fresh download silently replaces old history. |
| Identity and corporate actions | Stable identifiers, dated ticker mappings, splits, dividends, mergers and raw versus adjusted values. |
| Delivery and support | File or API schema, limits, update schedule, outage notices, recovery/replay procedure and a route for resolving suspect records. |
| Contract | Permitted users and uses, retention, redistribution, derived outputs, upstream entitlements and termination terms for the intended workflow. |
An “adjusted” price series does not by itself establish point-in-time integrity. Corporate actions and survivorship bias require their own checks. Equally, a column named
timestamp does not identify a universal clock. As a concrete documentation example, Databento distinguishes publisher event time, its own receive time and sending time. Its receive time is not the client's local receipt time. These are provider-specific field definitions, not a ranking of feeds.For a worked method of reconstructing eligible historical records, use the Point-in-Time Data lesson. Its public preview outlines the topic; the full lesson requires membership.
Delivery, data quality and rights are separate tests
Successful transport establishes that a response arrived, not that its economic meaning matches the model. Reconcile sampled records to a primary source where practical, inspect missing and duplicate keys, and test a known corporate action or correction. Preserve the delivered snapshot, request parameters and transformation versions so a later result can be reproduced. The APIs lesson demonstrates response validation with offline Python fixtures; it has a public preview and requires membership for the full lesson.
A commercial intermediary is not always necessary. For example, the U.S. SEC provides EDGAR APIs for filing histories and extracted XBRL facts without API keys. That direct access still leaves the user responsible for interpreting units, filing contexts, historical availability and access requirements. A vendor may add useful normalisation or service around such a source; a direct feed and a prepared database are different deliverables.
Treat financial data licensing as part of the specification. Technical access does not establish permission to redistribute data or publish derived outputs. NYSE's connectivity documentation, for example, requires applicable documentation for customers and vendors receiving, using or redistributing its market data through an uncontrolled feed. The relevant agreements determine the actual rights; a vendor subscription alone is not a universal entitlement.
Choose a feed against the declared workflow, and retain evidence of the checks. Row count, delivery reliability, information eligibility and permitted use answer different questions.
Sources
- Rishi K. Narang, Inside the Black Box: A Simple Guide to Quantitative and High-Frequency Trading, second edition (Wiley, 2013), Chapter 8, pp. 135–139, particularly “Sources of Data,” pp. 137–138.
- Databento documentation: Common fields, enums, and types, timestamp definitions and index timestamp.
- NYSE: Connectivity Documents, documentation for receipt, use and redistribution through uncontrolled datafeeds.
- SEC: EDGAR Application Programming Interfaces, submissions and XBRL endpoints, authentication and update descriptions.