---
title: FIX Message Layouts
description: Interpret FIX field tables, understand exchange presence requirements, and apply field ordering rules to framing and repeating groups.
---

This reference explains the field tables in the [Market Data](/api-reference/fix/market-data) and [Order Entry](/api-reference/fix/order-entry) references. [FIX Data Types](/reference/fix-data-types) defines value formats and examples.

## Field Order

Tables follow dictionary declaration order. Ordinary message-body fields do not need to follow that order. Header, trailer, and repeating-group fields have specific ordering rules.

A message contains its header, then its body, then its trailer. The header begins with the protocol version, body length, and message type, in that order. The checksum is the last field in the message.

The shared [Header and Trailer](/api-reference/fix/header-and-trailer) reference applies to both session-level and application-level messages in both FIX APIs.

These distinctions follow the FIX Trading Community's [field ordering rules](https://forum.fixtrading.org/t/does-ordering-of-tags-matter/13998).

## Repeating Groups

The count field immediately precedes the group's entries. Each entry begins with the first field shown in its table, and its fields follow the listed order. Keep each entry's fields together; a nested group's count and entries belong inside the containing entry.

For example, `NoRelatedSym(146)=2` introduces two instrument entries. Use the message's group table to identify the fields belonging to each entry.

### Empty Groups

A zero counter, such as `NoMDEntries(268)=0`, means the group contains no entries. No entry fields or nested groups for that group follow the counter.

| Counter | Meaning | Requirement |
| --- | --- | --- |
| Zero | The counter is present and declares no entries. | The message must permit an empty group. |
| Omitted | The group is not provided. | The message must permit omission of the counter. |

Counter presence and permission to send an empty group are separate message requirements. Zero is not universally valid, and a counter is not universally required. Follow the message's Presence and Behavior columns. Required fields inside an entry do not themselves require an entry to exist.

## Field Presence

The Presence column describes the exchange's contract using three labels.

| Presence | Meaning |
| --- | --- |
| Required | Must be included in messages sent to the exchange; always included in messages sent by the exchange. |
| Optional | May be omitted. |
| Conditional | Presence follows a concrete rule explained in Behavior, such as the request type, direction, recipient role, or another field. |

Inside a repeating group, presence applies within each entry that exists; it does not require the parent group or an entry to exist. For header and trailer layouts, Required means the field must be present in that part of the message.

A field that may simply be unavailable is Optional. Information availability alone does not make a field Conditional.

The Behavior column explains conditions, including differences between messages sent to and by the exchange, quantity alternatives, empty-group rules, and fields ignored by the exchange. Fields the exchange never sends are labeled Optional, with a note in Behavior. Dictionary-only messages are not accepted or sent by the exchange; their fields are included for completeness.

Supported values list only values accepted in messages sent to the exchange or included in messages sent by the exchange. Follow the accompanying conditions for direction, role, and combinations with other fields. Ignored inputs identify their accepted values separately; these values do not change exchange behavior. Downloadable dictionaries may contain broader declarations; those declarations do not expand the supported values or override the Presence column.