Skip to content

Venues

A venue is where a price or a trade comes from: an exchange, an alternative trading system, a crypto exchange, a dealer network, or a facility trades are reported to. Every venue a deployment names has an ID of the platform's, VEN- followed by letters and digits, from the platform's venue master, kept beside the security master. A deployment pulls the venues it needs from it, one at a time, and never mints one.

A venue ID, and its codes

A venue's ID is the answer; its codes are attributes, as an instrument's ticker is an attribute of the instrument (see Instruments). A venue may be known by:

  • its MIC, the ISO 10383 market identifier code, operating or segment, under the scheme iso10383, where it has one. A crypto exchange or a dealer network may have none;
  • vendors' codes, each a symbol with the vendor as its source, such as Alpaca's one-letter exchange codes (V for IEX).

Each code is dated: a MIC names the venue in force on the date it is asked about.

A venue's record What it holds
venue_id Its VEN- ID, never changed and never reused.
name Its name. A rename is an amend, the old name kept in its dated history.
country_code Where it operates, ISO 3166-1 alpha-2.
kind exchange, alternative_trading_system (FX's anonymous central books among them), crypto_exchange, dealer_network (RFQ, OTC and, for now, IOI networks) or reporting_facility (reported to, not traded on).
identifiers Its MIC and vendors' codes, each in force from a date.
operating_venue_id For a segment, the venue it belongs to.
time_zone The IANA zone its trading day is defined in: America/New_York for a US equity venue, Etc/UTC for a crypto exchange.
lifecycle_state Active, or decommissioned: closed, or its MIC expired. A decommissioned venue still resolves for a date it was in force.

The record is the platform's, at the platform's version; a deployment keeps it as pulled and changes nothing in it. The whole record is in the data dictionary.

Pulled when needed

A deployment asks the platform for a venue only when something names one it does not hold, by the venue's public codes alone, and never pulls the whole list. A plugin resolves a code it read to a venue ID through its sidecar (resolve_venue); the deployment answers from the venues it holds.

Where none answers, the plugin reports the venue missing (report_missing_venue), and carries on. The deployment asks the platform for it, once, and again only after ten minutes. A row naming a venue the deployment does not hold yet names none, and keeps the code as the source reported it, so the venue is not lost; the Data sources page counts the miss against the dataset. Once the platform's curation has vetted the venue and the deployment holds it, it resolves like any other.

A plugin never adds a venue, and neither does a deployment: a new venue is a new record in the venue master, never a change to the contract.

Where a deployment names a venue

  • A lake row's source (Source.venue_id): the venue a price printed on. Empty is the consolidated view across venues.
  • A dataset's catalogue entry (DatasetDeclaration.venue_id): the venue a dataset is, where it is one venue's; empty for a consolidated dataset.
  • An instrument's listing venue (InstrumentRecord.listing_venue_id), in place of its MIC: a segment's venue where the listing is on one. The instrument's exchange_mic is deprecated, and read until every record carries a venue ID.
  • On the order path: a placement's destination, set by the ems, and an execution's place of execution, reported by the connectivity plugin, each a venue ID resolved at the edge; a connectivity plugin resolves and reports a missing venue as a data plugin does. A trading calendar names the venues that follow it (see Settlement calendars).