Source: https://databento.com/docs/datasets/xpsx-itch


# Nasdaq PSX TotalView-ITCH

**Dataset ID**: [XPSX.ITCH]($PLATFORM_HOSTNAME/catalog/us-equities#XPSX.ITCH)

Nasdaq PSX disseminates full depth-of-book data for their exchange through their TotalView-ITCH feed over the MoldUDP64 protocol, which Databento receives over UDP multicast in our NY4 data center.

PDF specifications are available on Nasdaq's website for [Nasdaq TotalView-ITCH](http://www.nasdaqtrader.com/content/technicalsupport/specifications/dataproducts/NQTVITCHSpecification.pdf) and [MoldUDP64](http://www.nasdaqtrader.com/content/technicalsupport/specifications/dataproducts/moldudp64.pdf).

### Symbol convention

Raw symbols in this dataset use the **Nasdaq** convention (e.g. `BRK.B`, `AAC+`).
See [CMS vs. Nasdaq symbology](https://databento.com/docs/conventions/symbology.md#raw-symbol) for the per-dataset convention map.

### Timestamps

Nasdaq PSX TotalView-ITCH messages received by Databento have at most one timestamp, which has nanosecond precision.
As with all of our datasets, we also collect a `ts_recv` timestamp when the packet was received by our capture server.

The extra field `ts_in_delta` does not convey any additional information for this dataset, and is equivalent to `ts_recv - ts_event`.

| Databento Field | TotalView Field | Description |
| `ts_recv` | N/A | The capture-server-received timestamp. |
| `ts_event` | Timestamp | The matching-engine-received timestamp. |

More details about our timestamps are available in our [timestamping guide](https://databento.com/docs/architecture/timestamping-guide.md).

### MBO normalization

**Order lifecycle messages**

There are seven message types in TotalView that change the state of the order book.
Databento normalizes these messages to MBO records as follows:

- *Add Order - No MPID Attribution*: **A**dd
- *Add Order with MPID Attribution*: **A**dd, but the attribution field is not included
- *Order Executed*: **T**rade, **F**ill, then **C**ancel
- *Order Executed with Price*: **T**rade, **F**ill, then **C**ancel, but the initial **T**rade is omitted if the message is marked as non-printable
- *Order Cancel*: **C**ancel, with the `quantity` indicating the number of shares to remove from the display size
- *Order Delete*: **C**ancel, with the `quantity` indicating the current display size of the order
- *Order Replace*: **C**ancel with the previous `order_id`, followed by **A**dd with the new `order_id`

All **T**rade records will have `order_id` set to `0`, because Nasdaq does not provide information about the aggressor's order.
Normalized records from the same TotalView message will have the same `sequence`.

**Trade messages**

TotalView also has two messages for providing execution details for match events against non-displayed orders or cross events.

Databento normalizes both *Trade (Non-Cross)* and *Cross Trade* messages into a single MBO **T**rade record with side **N**one.

### Definition normalization

Definition records are sourced from Stock Directory messages.

| Databento Field | TotalView Field | Description |
| `exchange` | Market Category | Normalized to the MIC code of the listing venue. All Nasdaq-listed instruments will normalize to `XNAS`. |
| `security_type` | Issue Classification | Identifies the security class for the issue as assigned by Nasdaq. A list of the different values and their meanings can be found in Appendix D [here](https://www.nasdaqtrader.com/content/technicalsupport/specifications/dataproducts/NQTVITCHSpecification.pdf). |
| `secsubtype` | Issue Sub-Type | Identifies the security sub-type for the issue as assigned by Nasdaq. A list of the different values and their meanings can be found in Appendix E [here](https://www.nasdaqtrader.com/content/technicalsupport/specifications/dataproducts/NQTVITCHSpecification.pdf). |

### Flags normalization

The `F_PUBLISHER_SPECIFIC` flag provides no additional meaning in this dataset and can be safely ignored.