Market data entitlement management for trading platforms is the control layer that decides whether a particular person, organisation or service may view, export or use a licensed data product at a particular time. It is not simply an API authorization check. A correct decision may depend on the instrument, venue, data tier, delay, subscriber category, contract acceptance, destination and intended use.

That distinction matters because a quote feed is not automatically public application data. The same symbol can be real-time for one subscriber, delayed for another, available only as end-of-day data for a third, and prohibited entirely for a fourth. Display, API delivery, file export, alert evaluation and machine-driven decisioning can also carry different permissions. The applicable exchange, vendor and customer agreements remain the source of legal obligations; the entitlement layer is how a product consistently enforces the rules it has been configured to follow.

Model an entitlement as a decision, not a plan name

A role such as trader, analyst or administrator is useful for product workflow, but it is too broad for financial market data licensing controls. A robust authorization decision should evaluate:

  • Subject: user, service account or named organisation member;
  • Tenant and account: one individual may have separate subscriptions in separate organisations;
  • Data product: quote, trade, top of book, depth, reference data, history or derived analytics;
  • Market scope: venue, MIC, asset class, instrument universe or individual instrument;
  • Freshness: real-time, delayed or end-of-day;
  • Action: display, API read, export, alert evaluation, webhook delivery, model input or order-validation use;
  • Conditions: agreement version, professional classification, territory, device/session cap and effective dates.

Keep platform roles and data entitlements separate. A customer-success administrator should be able to suspend a specific exchange depth subscription without rewriting the user’s entire application role. Equally, a user may be permitted to view delayed quotes but not export them, create alerts from them or feed them into an automated workflow.

Use separate catalogues for instruments and licensed data products

An instrument master answers questions such as symbol mapping, ISIN, currency, asset class, venue and trading status. It should not be the only basis for permissions. Create a separate data-product catalogue with entries such as “Venue A equities, real-time top-of-book display” or “Venue A equities, delayed display”. Each product maps to a defined universe of instruments and to permitted actions.

At minimum, the entitlement domain normally needs these records:

  • Entitlement grant: subject, product, allowed actions, effective period, status and grant source;
  • Agreement acceptance: agreement version, acceptance timestamp and evidence tied to the appropriate user or organisation;
  • Usage policy: export limits, concurrency constraints, geography and display/non-display conditions;
  • Decision record: policy version, inputs, outcome and reason code for a requested action.

This separation prevents fragile permission logic when a vendor changes a symbol, a venue adds instruments, or the commercial team introduces a new package. It also makes it possible to version a policy without rewriting historical audit evidence. For example, ESMA guidance describes delayed data as data made available 15 minutes after publication in its market-data context. Do not hard-code that number as a universal truth: make delay a product-level configuration and label the freshness clearly in the interface.

Centralize decisions; enforce them at every delivery path

Hiding a chart control in the frontend is not enforcement. A web dashboard, mobile client, REST or GraphQL API, websocket gateway, scheduled export worker and alert engine must reach the same answer.

A practical design uses a central Policy Decision Point (PDP) that evaluates requests such as: “Can subject S perform action A on data product P for instrument I now?” The API gateway, data service, streaming gateway, export job and notification worker act as Policy Enforcement Points (PEPs). They call the PDP directly for sensitive actions or validate a short-lived signed entitlement token issued from the same decision logic.

Do not reduce that token to a broad claim such as premium=true. Bind it to tenant, product codes, actions, policy version and a short expiry. Check authorization when a stream is opened, then listen for entitlement-change events. On revocation, close affected websocket subscriptions, cancel queued exports and require alert or automation workers to re-evaluate access before their next use of the data.

Design cache boundaries around entitlement tiers

A common leakage path is a server-side cache keyed only by symbol and interval. If it stores a real-time result, a delayed subscriber can receive the wrong tier even when the UI badge says “delayed”. Cache keys must distinguish at least the data product or freshness tier, market scope and, where necessary, tenant and permitted purpose.

A safer pattern keeps raw feed data in a trusted backend zone, applies the entitlement filter before constructing a customer response, and separately caches the filtered representation. For streams, avoid exposing one generic public topic such as quotes:AAPL. Let a subscription service attach the connection to an internal channel selected by its authorized data tier. The client should never choose a vendor feed or a broad broadcast topic directly.

Alerts need the same discipline. Permission at alert creation is not enough. When the condition becomes true, the worker must verify that the alert remains licensed, that delivery remains permitted and that a revoked user or organisation cannot receive a notification based on data it no longer has the right to use.

Treat export, non-display use and “act” permissions independently

Permission to show a quote is not permission to create a CSV, email a report or expose an API response for downstream redistribution. Model export as its own action with constraints for format, row count, date range, destination and expiry. Generate files server-side, record the request, issue short-lived download access and block undelivered files when the related entitlement is revoked.

Non-display use also needs its own action. A system reading data for risk checks, signal generation, smart routing, model inputs or automation may be using it differently from a human looking at a chart. Likewise, separate the right to act from the right to view: a subscriber may be allowed to see a price but not create a data-driven alert, trigger a webhook or use that product in an order workflow. Recent exchange policy materials continue to distinguish display and non-display usage, so implementation should not assume that one subscription category covers both.

Make audit records reconstructable

Audit logging is more than a security feature. It supports support investigations, billing reconciliation, operational reporting and evidence of how the platform made a decision. Record the subject, tenant, product, venue/instrument scope, action, outcome, reason code, policy version, correlation ID and timestamp. Avoid logging quote payloads or reusable credentials unless there is a specific, secured requirement.

Your operations team should be able to answer: “What tier could this user access on a given date?”, “Why did an export fail?”, “How quickly did revocation reach active sessions?” and “Which service account consumed non-display data?” These concerns fit naturally into a FinTech & Trading Systems architecture. They are particularly important for analytics products such as ESFX, where data provenance, user context and a responsive product experience must work together.

Release checklist for a market-data permission system

  • Each product has explicit display, API, export, alert and non-display actions.
  • Real-time and delayed payloads are visibly distinguished and cannot collide in cache.
  • Web, mobile, API, websocket and background services share one decision model.
  • Subscription, agreement, user-status and organisation changes publish revocation events.
  • Active streams, exports and alerts are rechecked after revocation.
  • Audit events preserve the decision reason and policy version in force at the time.
  • Legal and operations teams have mapped the specific vendor or venue terms to configurable product policies.

Build the entitlement layer as a data-distribution boundary, not a late-stage feature flag. POLADO can help design a new market-data product, assess an existing entitlement model or implement consistent controls across client applications and backend services. Contact us to discuss your feeds, subscriber types and operational requirements.