Historical Price Exchange

Request Structure

When requesting historical prices, the following information is transmitted:

• Instrument identification: ISIN + currency (securities) or currency pair
• Date range: From-date (typically the last locally available price + 1 day) to to-date

Data Exchange Workflow

The exchange of historical prices follows a multi-step process with a special feature: the “want to receive” mechanism.

flowchart TD
    A[Request for historical prices] --> B{GT-Net enabled?}
    B -->|No| C[No action]
    B -->|Yes| D[Query Push-Open servers]
    D --> E[Query Open servers]
    E --> F[Store received data]
    F --> G{Want-to-receive responses?}
    G -->|Yes| H[Push historical data back]
    G -->|No| I[Done]
    H --> I

Detailed Workflow

Step 1: Query Push-Open Servers

First, all configured push-open servers are queried by priority:

• The request contains the instrument list with the desired date range.
• The response contains OHLCV data (open, high, low, close, volume) for each available day.

Step 2: Query Open Servers

For instruments not yet filled, open servers are queried. These can additionally return “want to receive” markers.

Step 3: Store Received Data

The storage of received historical prices depends on whether the instrument exists locally:

flowchart LR
    A[Received prices] --> B{Instrument local?}
    B -->|Yes| C[historyquote table]
    B -->|No| D[gt_net_historyquote table]

The “Want to Receive” Mechanism

A special feature of historical price data exchange is the bidirectional data exchange via the “want to receive” mechanism.

How It Works

When an open server cannot provide data for a requested instrument but wants to receive data for this instrument, it sends back a “want to receive” marker:

• The marker contains the date from which data is desired.
• The requesting server checks if it has local data for this instrument.
• If yes, it proactively sends this data to the interested server.

sequenceDiagram
    autonumber
    participant A as Requesting Server
    participant B as Open Server

    A->>B: Request: Historical prices for Instrument X
    Note over B: Has no data,<br/>but wants to receive
    B-->>A: Response: Want to receive from Date Y
    Note over A: Checks local data
    A->>B: Push: Historical prices from Date Y
    Note over B: Stores received data

Benefits of the Mechanism

• Bidirectional exchange: Both servers benefit from the data exchange.
• Automatic completion: Servers can automatically fill data gaps.
• Efficiency: Data exchange occurs specifically for needed time periods.

Differences from Intraday Exchange

Data Quality

When storing received data, duplicates are avoided:

• Before storing, the system checks if an entry already exists for the date.
• Only new records are stored.
• Existing data is not overwritten.