Swiss pre-open market data: a schema and test harness for indicative prices

Decision: store a theoretical opening price as an indicative auction observation, never as a trade. During the pre-opening phase, the exchange collects intentions; the theoretical price can change, and the displayed value does not prove that a transaction occurred. Keep the last executed trade, indicative auction value, opening-auction result, and first continuous-market trade in separate fields. That one boundary prevents a surprising number of bad dashboards, alerts, and backtests.

For investor background, market analysis CH/EU’s Swiss pre-opening explainer explains why the indication is not a guaranteed course. This companion article turns the distinction into a data contract, a small validation harness, and an operational checklist for anyone ingesting or displaying Swiss equity market data. The exchange’s current SIX Trading Hours rules are the controlling source for phases, segment-specific schedules, and the opening auction. Always verify the relevant instrument and market segment before implementing a schedule.

The short answer for a product team is practical: an indicative price is useful context, but it is not a fill, a firm quote, or a forecast. If your schema has one generic price column, your system cannot reliably distinguish the four different facts users may see around an opening. Fix the model before adding more dashboards.

Who should use this

This guide is for market-data engineers, broker-platform product owners, analytics teams, and analysts who consume an exchange or vendor feed. It is not a trading recommendation and does not describe how a retail client can route an order. A broker may accept an order during a particular phase while the exchange has not yet executed it. The broker’s interface and the exchange’s matching state are different layers; record both when the feed supports them.

A data team has a specific responsibility: preserve the meaning the source assigned to an observation. The team should be able to answer, for every displayed number, whether it came from an actual execution, an indicative auction calculation, a quote, a previous close, or an adjusted reference. If the raw feed cannot answer that question, the dashboard should show status unknown or suppress the label rather than guess.

The mechanism can be summarized in one sentence: phase is part of the value. A numerical price without its phase, timestamp, instrument, and source type is incomplete data. The same number can be a prior close, a theoretical opening indication, an auction execution, or a later continuous-market trade. Those meanings are not interchangeable.

The four observations that must not be collapsed

Start by naming the objects rather than the screens. A user interface may visually place them near one another, but the data contract should keep them separate.

Observation	What it means	What it does not prove	Safe default label
Previous official close	The last eligible price from the prior session, according to the relevant source	That today’s opening will occur there	Previous close, with session date
Indicative auction value	A provisional value calculated from the current auction book under the applicable phase rules	That a trade occurred, that an order will fill, or that the next displayed value will persist	Indicative opening price
Opening auction execution	An executed opening result when an opening auction actually produces a trade	That every instrument opened at the same moment or that this is the day’s final reference	Opening auction trade, with execution time
First continuous-market execution	A later trade after continuous trading starts for that segment and instrument	That it equals the auction result or represents all available liquidity	First continuous trade

This table is a contract for names, not a calculation formula. The exchange determines auction mechanics. A downstream platform should not infer the result from a chart, from the last close, or from a vendor field whose semantics have not been documented.

The detailed SIX schedule matters because “the Swiss market opens at 09:00” is too broad to be a reliable software rule. SIX lists hours by market segment and product. Its rules describe pre-opening, the opening auction, and continuous trading; for individual securities, the opening moment can be randomized within a two-minute interval. The published schedule also distinguishes segments such as shares, bonds, and other products. Treat the segment and instrument as required input, not optional metadata.

The overview video on SIX’s investor education page is a useful orientation for readers learning how orders and prices relate. An overview is not a feed specification: use the current Trading Hours page and your market-data vendor’s instrument-level schema for exact phase behavior. During this research run, the video page was available but an accessible transcript was not; no operational claim in this article depends on an unverified video statement.

Why a single price field fails

Imagine a monitoring service that receives symbol, price, and timestamp. It plots the price and calls it “market price.” If the vendor’s value is theoretical, the chart has silently transformed an auction indication into a claimed trade. A portfolio analyst might then compare it with a previous close and compute an apparent return. A notification system might tell a user that a security has “opened” even when the auction has not executed.

This is not a small naming issue. It changes what a person can reasonably infer. “The last trade was CHF X” is an execution statement. “The theoretical opening value was CHF Y at time T” is a statement about a particular snapshot of an order book. “The first continuous trade was CHF Z” is an execution statement at a later state. A system that flattens them into one field erases the evidence required to resolve disagreements.

Do not solve the problem by using a string prefix such as indicative_price in one service while another service calls the same value open. Enforce semantics at ingestion, storage, API serialization, chart series, export, and alert generation. A reliable system carries the same type distinction end to end. A label in the user interface cannot restore information already discarded in a database.

A practical data contract

The following contract is deliberately small. Add provider-specific fields where needed, but do not remove the semantic fields merely because a particular feed does not populate all of them.

Field	Type	Requirement	Example meaning
instrument_id	Stable instrument identifier	Required	Identifies the security, not only its display ticker
venue	Exchange or source venue	Required	SIX Swiss Exchange, or a documented vendor venue code
segment	Controlled string or reference	Required when known	Equity, bond, ETF, or the exact provider segment
phase	Enum	Required	PREOPEN, OPENING_AUCTION, CONTINUOUS, CLOSING_AUCTION, POSTTRADE, UNKNOWN
observation_type	Enum	Required	INDICATIVE_AUCTION, TRADE, QUOTE, REFERENCE, UNKNOWN
price	Decimal with currency	Nullable	The value itself; its type is defined by observation_type
currency	ISO currency code	Required when price exists	CHF, EUR, or another instrument currency
event_time	Timestamp with timezone	Required	When the source says the observation applied
received_at	Timestamp with timezone	Required	When your system received it
source_sequence	Vendor or exchange sequence	Strongly recommended	Detects gaps, repeats, or reordering
auction_status	Enum or provider value	Required for auction observations	INDICATIVE, DELAYED, NON_OPENING, EXECUTED, NO_RESULT, UNKNOWN
executed_quantity	Decimal or integer	Required for trade observations if available	Distinguishes an execution from a theoretical value
bid_depth and ask_depth	Decimal or count by level	Optional but typed	Visible depth at specified price levels, not total market liquidity
reference_basis	Enum or source value	Required for reference comparisons	Raw previous close, adjusted reference, or vendor-specific basis
corporate_action_id	Nullable stable event ID	Optional	Links an ex-date, split, distribution, or other relevant event
source_payload_hash	Digest	Recommended	Connects an output to the exact raw payload without copying secrets

The field names are proposed, not SIX API names. No SIX feed schema is implied here. Map provider fields into this contract through a reviewed adapter and retain the raw provider message under your normal retention policy. If there is no reliable mapping for phase or observation_type, set it to UNKNOWN; never fabricate a more informative value.

Every timestamp should carry an explicit offset or be normalized to UTC while preserving the source timezone and original timestamp. A bare 09:00 is ambiguous: it can be a local exchange time, a server time, or a user’s display time. Daylight-saving changes create avoidable errors if an ingestion job assumes a fixed UTC offset. Store the received timestamp as evidence; do not overwrite it with a later display timestamp.

A data model should also separate missing from zero. If no opening execution exists, executed_quantity is null or absent, not zero with a fabricated price. If the theoretical value is unavailable, leave price null and preserve the provider’s status. A zero price is a valid numeric value in some instruments or data contexts; using it to mean no result invites arithmetic and charting bugs.

The six-state interpretation ledger

The reusable asset in this article is an interpretation ledger with six states. It is designed for an analyst reviewing a feed snapshot, not for computing the exchange’s auction price.

1. PREOPEN_INDICATIVE: the feed is in pre-opening, a theoretical value is present, and no execution is asserted.
2. PREOPEN_NO_INDICATION: the feed is pre-opening, but no theoretical value is available or its value has been withheld.
3. OPENING_DELAYED: the expected transition to the opening result has been delayed or the provider explicitly says the instrument has not opened.
4. OPENING_NON_OPENING: the provider or official source reports that no opening auction result was produced for the instrument.
5. OPENING_EXECUTED: an opening-auction execution is explicitly present, with its execution fields.
6. CONTINUOUS_FIRST_TRADE: continuous trading is in effect and the first eligible continuous-market trade has been identified.

The ledger is intentionally stricter than many dashboards. An adapter can return UNKNOWN if the vendor’s state cannot be mapped. An unknown state is operationally useful: it blocks the UI from making an unsupported “opened” claim and creates a task to resolve the mapping. It is not a reason to guess based on a time-of-day threshold.

A downstream application should not replace an explicit OPENING_DELAYED or OPENING_NON_OPENING state with an assumed normal opening. A delayed state is an event, not a failure in the data model. A no-opening result is not the same as zero volume after a trade. Preserve the difference so incident teams can identify whether the source reported no auction result, the feed omitted a message, or your system failed to receive it.

stateDiagram-v2
    [*] --> PREOPEN_INDICATIVE: theoretical value present
    [*] --> PREOPEN_NO_INDICATION: no value available
    PREOPEN_INDICATIVE --> OPENING_DELAYED: provider reports delay
    PREOPEN_NO_INDICATION --> OPENING_DELAYED: provider reports delay
    PREOPEN_INDICATIVE --> OPENING_EXECUTED: explicit auction trade
    PREOPEN_NO_INDICATION --> OPENING_EXECUTED: explicit auction trade
    PREOPEN_INDICATIVE --> OPENING_NON_OPENING: explicit no-result status
    PREOPEN_NO_INDICATION --> OPENING_NON_OPENING: explicit no-result status
    OPENING_DELAYED --> OPENING_EXECUTED: explicit auction trade
    OPENING_DELAYED --> OPENING_NON_OPENING: explicit no-result status
    OPENING_EXECUTED --> CONTINUOUS_FIRST_TRADE: first continuous trade
    OPENING_NON_OPENING --> CONTINUOUS_FIRST_TRADE: later eligible trade, if one occurs

The diagram shows permitted transitions in a simplified downstream ledger; it is not an exchange protocol. Your feed can skip some intermediate messages, so the adapter may create a first observed state from a snapshot. Record transition_reason and source sequence to make that shortcut visible. The business rule is that a state transition must be supported by an explicit provider or exchange event, not by the clock alone.

Classification rules that fail closed

A compact classifier is useful only if it refuses to infer an execution. These rules are suitable for an adapter after the source mapping is validated:

• If phase is pre-opening and observation_type is indicative auction, return PREOPEN_INDICATIVE, even when a numeric value is present.
• If the provider reports pre-opening but provides no current theoretical value, return PREOPEN_NO_INDICATION.
• If the source explicitly reports a delay, return OPENING_DELAYED; do not derive a price from the previous close.
• If the source explicitly reports a non-opening or no-result condition, return OPENING_NON_OPENING.
• Return OPENING_EXECUTED only when the message has an execution identifier or a trusted execution event, and its time and quantity are populated according to the provider contract.
• Return CONTINUOUS_FIRST_TRADE only when the market phase is continuous and the event is an actual trade.
• If fields contradict one another, return UNKNOWN and quarantine the record rather than choosing whichever field looks plausible.

The exact provider fields vary. Some market-data services supply a dedicated auction status; others may only provide a quote type, a sequence of book updates, or instrument state events. Build a mapping table for each vendor and version, and have an exchange-market specialist review it. A mapping that is correct for one provider’s product should not be assumed correct for another feed, delayed redistribution product, or snapshot endpoint.

function classifySnapshot(s) {
  const phase = String(s.phase || "UNKNOWN").toUpperCase();
  const type = String(s.observationType || "UNKNOWN").toUpperCase();
  const status = String(s.auctionStatus || "UNKNOWN").toUpperCase();

  if (status === "DELAYED") return "OPENING_DELAYED";
  if (status === "NON_OPENING" || status === "NO_RESULT") {
    return "OPENING_NON_OPENING";
  }

  const hasExecution =
    Boolean(s.executionId) &&
    s.eventTime != null &&
    s.executedQuantity != null;

  if (phase === "PREOPEN" && type === "INDICATIVE_AUCTION") {
    return s.price == null ? "PREOPEN_NO_INDICATION" : "PREOPEN_INDICATIVE";
  }

  if (phase === "OPENING_AUCTION" && hasExecution && status === "EXECUTED") {
    return "OPENING_EXECUTED";
  }

  if (phase === "CONTINUOUS" && type === "TRADE" && hasExecution) {
    return "CONTINUOUS_FIRST_TRADE";
  }

  return "UNKNOWN";
}

This code is a guardrail example, not a SIX calculation or a complete parser. It assumes your adapter has already mapped provider semantics into the input names shown. It does not decide order priority, determine auction price, estimate an execution probability, or verify that a feed is licensed for redistribution. Production code should validate decimal precision, currency, timestamp offsets, source sequence, instrument identity, and the provider’s event definitions.

A useful test harness checks both the ordinary path and contradictions. The three fixtures below are synthetic examples, not observations of real securities or exchange outcomes. Their purpose is to verify labels and fail-closed behavior; they do not estimate the frequency of delays or no-opening cases.

const cases = [
  {
    name: "theoretical indication is not a trade",
    input: {
      phase: "PREOPEN",
      observationType: "INDICATIVE_AUCTION",
      auctionStatus: "INDICATIVE",
      price: "121.40"
    },
    expected: "PREOPEN_INDICATIVE"
  },
  {
    name: "explicit no-result is not a zero-price trade",
    input: {
      phase: "OPENING_AUCTION",
      observationType: "UNKNOWN",
      auctionStatus: "NO_RESULT",
      price: null
    },
    expected: "OPENING_NON_OPENING"
  },
  {
    name: "a price without an execution identifier stays unknown",
    input: {
      phase: "OPENING_AUCTION",
      observationType: "TRADE",
      auctionStatus: "EXECUTED",
      price: "121.55",
      eventTime: "2026-10-30T07:00:31Z",
      executedQuantity: null,
      executionId: null
    },
    expected: "UNKNOWN"
  }
];

for (const test of cases) {
  const actual = classifySnapshot(test.input);
  if (actual !== test.expected) {
    throw new Error(test.name + ": expected " + test.expected + ", got " + actual);
  }
}
console.log(cases.length + " synthetic classification cases passed");

In a real repository, run this harness in the same package as the vendor adapter and add one fixture from each documented status code, with all proprietary identifiers removed. Keep an explicit test for every source transition that the UI labels as an execution. A regression test should fail when a provider changes its payload or an adapter begins to interpret a quote as a trade.

A no-surprises ingest workflow

Use an ordered pipeline so that a strong downstream system cannot accidentally repair weak upstream evidence by guessing.

1. Capture the raw event. Store the payload or a privacy-safe immutable reference, source, provider version, receipt time, sequence number, and checksum. Do not discard the original phase, status, condition codes, or field names when normalizing. If retention rules prevent payload storage, retain an approved hash and the minimum audit fields needed for reproducibility.

2. Resolve the instrument. Map the vendor identifier to a stable instrument identifier. Tickers can be reused, change, or be ambiguous between listings and share classes. A missing or stale mapping should stop enrichment. Never match solely on a short symbol when the source provides an exchange or instrument code.

3. Normalize without changing meaning. Convert numeric representation and timestamps, but preserve the raw value and currency. Do not apply a currency conversion in the same field as the source price. If a decimal comes as a string, parse it using a fixed decimal library or exact decimal type rather than binary floating point for financial arithmetic.

4. Map phase and observation type. Use a reviewed, versioned mapping. Keep the vendor’s original state value alongside the normalized enum. If the vendor state is undocumented, set the normalized state to UNKNOWN and open a mapping task. A missing mapping is a data-quality condition, not a product decision.

5. Apply invariants. Reject or quarantine contradictory records. A pre-opening indicative observation must not have an execution ID or executed quantity unless the provider clearly documents a separate field with that name. A trade event should have execution evidence. A delayed state should not be silently converted to an opening. The previous close should retain the session date to which it belongs.

6. Publish a typed event. APIs should expose observation_type, phase, event_time, and a label source. A chart series should distinguish reference, indication, and trade, including a legend and accessible text. Export files should include the same fields, not only the formatted number.

7. Reconcile transitions. Compare source sequence and event time, identify gaps or reordering, and record whether the status came from a live event or a snapshot. If the provider offers a correction event, append the correction and preserve the original message; do not erase the audit trail.

This flow can be implemented as a stream processor or scheduled ingest job. The architectural choice matters less than the invariant: the meaning of an observation survives every transformation. If the API emits a bare open_price, downstream consumers will eventually use it as a trade, even if the front-end originally had a warning icon.

A decision matrix for feed and product teams

Condition	Normalize to	User-facing language	Operational response
Pre-opening phase with current theoretical value	PREOPEN_INDICATIVE	“Indicative opening price” and timestamp	Show provisional status; refresh as new source events arrive
Pre-opening with no theoretical value	PREOPEN_NO_INDICATION	“No indicative value available”	Keep the field blank; do not copy the previous close
Provider says the opening is delayed	OPENING_DELAYED	“Opening delayed” with source time	Wait for explicit state change; raise a feed-health alert if expected messages stop
Provider says no result or non-opening	OPENING_NON_OPENING	“No opening-auction result reported”	Preserve the source status; do not synthesize an opening value
Explicit opening-auction execution	OPENING_EXECUTED	“Opening-auction trade” with execution time	Record execution fields and market phase
First trade in continuous phase	CONTINUOUS_FIRST_TRADE	“First continuous-market trade”	Keep separate from the auction result
Fields disagree or the event type is undocumented	UNKNOWN	“Status unavailable” or suppress the price	Quarantine, investigate mapping, and retain the source event

A product team may choose not to display a provisional price at all. That is a legitimate decision when the feed is delayed, the source semantics are unclear, or the intended audience would likely interpret an indication as a guarantee. If the value is displayed, the label must be adjacent to it. A disclaimer elsewhere on the page is not a substitute for an accurate local label.

A testable product requirement can be written as: “Given an indicative auction message with a numeric price and no execution evidence, the chart never labels that observation as a trade, and the exported data includes its indicative type.” This is easier to verify than “make opening data clear.” Define the fixture, the expected API response, the chart label, and the CSV columns before implementation.

Reference prices, corporate actions, and apparent gaps

An opening indication is often compared with yesterday’s close. The comparison can be useful, but the baseline itself may need context. A raw closing price and an adjusted reference price answer different questions. On an ex-dividend date or after another corporate action, the exchange or vendor may apply a reference-price treatment that should not be confused with a new execution. SIX publishes its operational rules separately from issuer event information; record the basis and event identifier used by your application.

The CFA Institute’s 2026 refresher on dividends and share repurchases is useful for understanding payout policy as a distinct corporate-finance topic. It is not a SIX feed specification. The implementation lesson is to keep corporate-action facts in a separate event stream and document how a reference value was produced. Never infer an adjustment solely from a price gap.

The dashboard should expose whether a comparison uses raw close, adjusted reference, or another vendor-defined value. If the reference is adjusted, include the adjustment factor or source reference in the evidence record where licensing and data design permit. If the basis is unknown, do not present a percentage change as though its starting point were unambiguous.

Liquidity is more than the displayed price

A theoretical value can be numerically precise while the book around it is thin. Precision of display is not a measure of robustness. Record the depth levels and units the provider actually supplies, the timestamp of the snapshot, and whether the value is a single best level or an aggregate. A shallow displayed book can move materially if one order changes; a broader book may still not guarantee an execution at any given price.

PwC’s older global financial markets liquidity study discusses liquidity as multidimensional rather than a single quote. Treat it as a conceptual framework, not a current measurement of Swiss equities. In a production dashboard, define what your depth measure includes, its levels, and its time basis. Do not call a top-of-book number total liquidity unless the source and calculation justify that description.

A useful quality panel can show four separate statuses: freshness, depth availability, auction state, and execution evidence. The labels should not collapse into a green liquid badge. Green can mean only that required data arrived on time and passed validation; it cannot certify that a user will receive a particular execution or that all hidden liquidity is represented.

A note on auction research and market differences

Opening call auctions are studied in financial-market research, but findings from one exchange cannot automatically be transferred to another. A 2015 paper on opening and closing price efficiency, published in the Journal of International Financial Markets, Institutions & Money, examines London Stock Exchange data and reports that the information role of the opening auction differs with trading activity. That is a research finding about its sample and venue, not a current SIX statistic or a guarantee that a particular Swiss instrument has a more informative auction.

The practical implication is methodological: do not turn a general paper into an exchange-specific threshold. If you want to evaluate whether auction signals are useful for your product, define the venue, instrument universe, observation dates, event definitions, data entitlement, and missing-data policy first. Separate the question “was the displayed value a valid indication?” from the empirical question “did the indication help explain a later price?” The first is a data-contract issue; the second needs a defensible study.

SIX describes the opening auction as a mechanism based on executable interest, with a price determination rule and possible delayed or non-opening cases. That is the rule source. The academic result can help frame questions about price discovery, but it cannot override the exchange’s current market rules. A dashboard should reflect the actual event from the source, not a literature-inspired expectation.

Regulatory context and careful escalation

If an opening indication moves sharply, a monitoring service should first check the feed state, event chronology, instrument mapping, relevant corporate events, and the source’s data quality. A surprising number is not by itself evidence of misconduct, manipulation, or an exchange error. Keep those assessments separate and require the appropriate compliance or exchange-relations process before making a public allegation.

For example, the cited SIX Exchange Regulation communication on buyback programmes and price stabilization has a defined scope tied to reporting conduct for such programmes. It is not a general rule for labeling every unusual pre-opening indication. Use the document only for the boundary it actually covers. A compliance workflow should identify the exact rule, event type, and evidence that triggered escalation.

The same discipline applies to data corrections. A provider correction may mean the earlier payload was revised; it does not automatically mean an exchange event was unlawful or that a user experienced an execution. Preserve original and corrected values, source sequence, correction time, and downstream systems notified. Corrections should update the record of what the vendor now considers correct while retaining the audit history necessary to explain what was displayed earlier.

Monitoring and observability

Alert on broken invariants, not on price movement alone. Useful alerts include a phase/status combination the adapter has never seen, a trade without execution evidence, an indicative observation carrying an execution identifier, a timestamp outside the provider’s allowed tolerance, repeated source sequence numbers with different payloads, and a transition from delayed to normal that lacks an event. These conditions are concrete and actionable for an on-call data engineer.

Separate source-health alerting from market observations. A quiet book may be a valid market state. A missing heartbeat or stalled sequence may be a feed-health issue. A delayed auction message may be an exchange status. The same screen value can result from very different conditions, so the alert should include instrument_id, venue, phase, source event time, receive time, vendor, and adapter version.

Use a bounded clock-skew tolerance based on documented provider behavior and synchronized system clocks. Do not define it from a single day’s sample and call it a market rule. Record the tolerance version and owner. If the feed is delayed by design, represent that delay as an attribute; do not conceal it by changing event time to the receive time.

A clean incident note contains the raw event reference, normalized state, expected transition, actual transition, observed lag, affected interfaces, and the action taken. It should say “the feed status remained OPENING_DELAYED” rather than “the stock did not open” unless the exchange or trusted source actually says that. Precision in incident language reduces needless escalation and makes post-incident analysis possible.

Failure modes to test before release

Indicative price shown as a trade. Cause: adapter maps every numeric price to TRADE. Prevention: require event type plus execution evidence; use the synthetic test above; verify chart, API, and export behavior.

Clock-based opening inference. Cause: job changes the state to open at a fixed local time. Prevention: use the provider’s explicit phase transition and instrument segment; include randomized or delayed openings in fixtures; never substitute a schedule for an event.

Previous close copied forward. Cause: a missing theoretical value is rendered as yesterday’s price with today’s date. Prevention: separate reference observation and session date; keep missing values null; label previous close clearly.

Quote interpreted as guaranteed fill. Cause: UI does not distinguish a displayed quote from an execution. Prevention: show observation type and timestamp next to value; use indicative or quote accurately; do not promise execution.

Fields conflict. Cause: status says pre-opening while event type says trade, or an execution quantity is absent. Prevention: route to UNKNOWN, quarantine, log raw values, and alert the mapping owner.

Segment schedule copied across products. Cause: one hard-coded 09:00 time is applied to shares, bonds, funds, or another venue. Prevention: key schedules by instrument and segment; review against the current SIX table and provider calendar.

Corporate-action gap treated as a normal return. Cause: dashboard compares a raw close with an adjusted reference or misses an event. Prevention: store baseline type and corporate-action reference separately; use one documented calculation path for the displayed change.

Snapshot reordering. Cause: a late packet overwrites a newer sequence. Prevention: compare source sequence and event time, retain receive time, and make event replay deterministic.

A data entitlement issue looks like no auction. Cause: licensed feed omits a field or product tier. Prevention: distinguish no result reported from status unavailable; verify the specific data product and contract before escalation.

Evidence and source control

The primary operational evidence is SIX’s current Trading Hours page. It establishes that phase schedules vary by segment, pre-opening has its own behavior, and opening events are not reducible to a universal wall-clock rule. The linked investor video is only an orientation page in this article; because its transcript was not retrievable in this run, no technical rule here is attributed to its unseen narration.

The group’s French pre-opening article is a reader-facing explanation, not the authority for exchange behavior. This article adds a data contract and classification harness; its code is a proposed downstream control, not an official SIX implementation. The CFA source concerns dividend and repurchase analysis, PwC’s study is older and cross-market, and the SER communication concerns its stated buyback/stabilization context. Each is used only for that bounded point.

The 2015 opening-auction research is based on London, not Switzerland. Its result is not converted into a Swiss performance claim. The three code fixtures above are synthetic; the sample size of actual SIX quote snapshots in this article is zero. We did not run an empirical test on live order-book data, compare vendor latency, measure fill rates, or estimate returns. No reported percentage, average, or trading outcome in this article is an original market statistic.

The reproducible method is to map one vendor’s documented fields into the proposed enums, run the fixtures, then add anonymized recorded events only after the source license and retention rules allow it. Record date, vendor/product version, exchange segment, instrument selection, observation count, missing fields, event-time/receive-time policy, and excluded instruments. A future measured result should include those details and distinguish a vendor sample from the full exchange market.

Implementation checklist

Before shipping, answer every item with evidence:

• Does the raw event retain provider, product, version, sequence, original status, event time, and receive time?
• Is the instrument mapped to a stable identifier and the correct venue and segment?
• Are indicative values, quotes, references, auction executions, and continuous trades separate observation types?
• Can an indicative value appear only with an adjacent provisional label?
• Does an actual execution require a trusted execution event and the documented execution fields?
• Are no-result, delayed, no-indication, and unknown represented as separate states?
• Does the adapter fail closed when fields disagree?
• Are all timestamps timezone-aware, with raw source time preserved?
• Is the previous-close basis explicit, and are corporate actions kept in their own event stream?
• Do APIs, charts, alerts, and exports retain the same type distinction?
• Are provider mappings versioned and reviewed when a data product changes?
• Does every exception produce a traceable record without inventing an opening value?
• Can an on-call engineer replay the event and explain what the user saw?

A practical release gate is to block rollout until the data owner can demonstrate one valid indicative example, one explicit opening execution, one delayed state, one no-result state, and one contradictory payload that becomes UNKNOWN. These are acceptance cases, not a claim about how often each state occurs. If your source does not expose a particular case, document that gap instead of fabricating one to satisfy the checklist.

What the ledger does and does not do

The ledger protects the meaning of observations in software. It can stop a dashboard from presenting a provisional value as a trade, make an incident easier to investigate, and help a product team explain why two screens show different values. It cannot calculate the SIX auction price, predict the opening, tell a user whether to place an order, or prove that a particular vendor feed is complete.

That boundary is important for both trust and safety. A cleanly typed feed is not automatically a reliable investment signal. A correct display label does not guarantee data entitlement, low latency, complete depth, or execution. Conversely, a missing indicative value does not necessarily mean the system is broken; it may be a valid state or a provider limitation. Present these distinctions in the interface and the API contract.

The best operational result is modest but valuable: every price has a provenance, every phase has a source, and every “trade” claim has execution evidence. When the source cannot support the claim, return an unknown status and investigate. That is more useful than a confident value whose meaning disappeared somewhere between a vendor packet and a chart.

Final decision

Treat the theoretical opening value as a provisional auction observation. Preserve it separately from the previous close, opening execution, and first continuous trade. Model the phase and event type in the data contract; require explicit evidence before labeling an execution; and route contradictions to UNKNOWN rather than guessing from a clock or a numeric value.

For teams with existing feeds, the next step is not to rebuild the entire platform. Trace one instrument’s event from vendor payload to storage, API, chart, export, and alert. At every boundary, verify that phase, observation_type, timestamp, and source remain intact. Add the synthetic tests now, then validate the mapping against the provider’s documentation and actual licensed data. If the result is unclear, show the uncertainty and ask the vendor or exchange for the exact state definition.

This is a data-quality control, not an investment strategy. It helps people make a more accurate interpretation of market information, while leaving price discovery, execution decisions, and regulated advice where they belong.