A working market data feed answers a technical question: can the institution receive the data? It does not automatically answer a contractual question: may the institution use that data in a client report, financial product, calculation engine or shared service? Institutional procurement needs both answers before a feed becomes a dependency in production.
Kaiko's pricing and licensing page distinguishes enterprise plans, standard licensing and index licensing. Its exchange agreements page describes redistribution relationships with data suppliers. These vendor statements are useful evidence of licensing structure. They do not replace the contract covering an institution's own products and recipients.
Describe uses before comparing prices
Start with a usage inventory. Identify where data is displayed, where it enters calculations and where it is distributed externally. A valuation process, trading algorithm, public chart and client-facing index product can have different contractual requirements. Ask the provider to confirm the permissions for each intended use in writing.
Include affiliates and service providers. A central procurement team may buy a feed used by several legal entities, administrators and technology contractors. The licence should address those recipients rather than rely on an informal assumption that everyone inside an operating model counts as the same customer. Identify who controls access and how entitlements are reviewed.
Distinguish display from calculation
Showing prices to a user is different from using prices to determine a payment or trading decision. Kaiko's display product page expressly describes a display use that excludes input into financial calculations, trading or settlement. That example illustrates why a product name should be matched to the actual workflow.
For a hypothetical institution, the same feed might support a website chart and an internal risk model. A licence suitable for one use may need additional permissions for the other. Procurement should document both before deployment, then require review when a new team repurposes the feed. Technical reuse is easy; the permission to reuse must be established separately.
Examine derived outputs
A provider's contract may distinguish raw observations from aggregates, analytics and derived data. Review those definitions alongside the intended output. A daily closing price, risk score or chart can preserve different amounts of the underlying information. Whether an output is permitted depends on the applicable agreement, not simply on whether the institution performed a calculation.
Financial products add another question. Licensing a feed is not necessarily licensing a named benchmark or index for a product. Our article on crypto indices and benchmarks examines construction and governance; procurement should connect those choices to the relevant data and index permissions.
Preserve evidence and corrections
Risk and valuation processes need reproducible inputs. Confirm retention rights, historical access and the ability to keep records needed for audit or dispute resolution. Identify whether access to stored data continues after termination and which restrictions survive. A production process can become difficult to explain if its evidence must be deleted when a subscription ends.
Data quality also belongs in the contract review. Specify how corrections are communicated, whether revised histories can be retrieved and which version produced a published output. An institution should be able to explain a recalculation without assuming that a later API response reproduces the exact data originally used.
Map supplier dependencies
Ask how the provider obtains exchange data and what happens if a source withdraws access or changes its terms. A broad coverage list is a snapshot of available venues, not a guarantee that every dependency remains available indefinitely. Establish notice, substitution and escalation arrangements appropriate to the use case.
The operational fallback should also be licensed. A backup feed that has not been approved for valuation or redistribution may fail at the moment it is needed. Test switching sources and identify resulting changes in instrument mapping, timestamps and methodology. Our discussion of token identifiers and reference data explains why those mappings deserve explicit controls.
Give the licence an operating owner
Keep a register connecting each feed to products, entities, permissions and renewal dates. Review it when teams launch new outputs or share data with new recipients. The owner should be able to answer both whether a feed is reliable and whether the intended use remains permitted.
A good procurement outcome is a clear permission map supported by the executed agreement, together with tested data delivery and retention procedures. That turns licensing into an operating control rather than paperwork discovered after a successful integration.