LMEselect 9.

0 FIX Specification
December 2016

Please respond to:

Trading Operations
0207 113 8200

THE LONDON METAL EXCHANGE LME.COM

10 Finsbury Square, London EC2A 1AJ | Tel +44 (0)20 7113 8200
Registered in England no 2128666. Registered office as above.
  Cinnober Financial Technology AB

Contents
1 Document Overview ........................................................................................................................ 5
1.1 Intended Audience ........................................................................................................................ 5
1.2 Related Documents ...................................................................................................................... 5
2 About This Document ...................................................................................................................... 6
2.1 Revision History ............................................................................................................................ 6
2.2 Terms & Acronyms ....................................................................................................................... 6
3 Introduction ...................................................................................................................................... 6
3.1 Reading Instructions ..................................................................................................................... 6
4 FIX Session Layer ........................................................................................................................... 7
4.1 FIX Session Establishment ........................................................................................................... 7
4.2 Start of Day/End of Day Procedures ............................................................................................ 7
4.3 Reject Handling............................................................................................................................. 7
4.4 Authorization ................................................................................................................................. 8
4.5 Message Details ........................................................................................................................... 8
4.5.1 Logon .................................................................................................................................. 9
4.5.2 Logon after failover and reconnect ..................................................................................... 11
4.5.3 Heartbeat ............................................................................................................................ 13
4.5.4 Test Request ...................................................................................................................... 14
4.5.5 Resend Request ................................................................................................................. 14
4.5.6 Reject.................................................................................................................................. 15
4.5.7 Sequence Reset ................................................................................................................. 16
4.5.8 Logout ................................................................................................................................. 16
4.5.9 Disable Users ..................................................................................................................... 17
5 Business Layer Introduction ............................................................................................................ 17
5.1 User Interaction............................................................................................................................. 17
6 Order Management ......................................................................................................................... 20
6.1 Business Message Types ............................................................................................................. 20
6.1.1 Price Units .......................................................................................................................... 21
6.1.2 CFI Code ............................................................................................................................ 21
6.1.3 Maturity Dates .................................................................................................................... 22
6.1.4 Execution Reports for Multi-Leg Contracts......................................................................... 24
6.1.5 ExecID ................................................................................................................................ 24
6.1.6 OrderID ............................................................................................................................... 25
6.1.7 Stop Loss Order ................................................................................................................. 25

Page 2
  Cinnober Financial Technology AB

6.2 Message Details ........................................................................................................................... 25

6.2.1 New Order – Single ............................................................................................................ 25
6.2.2 Order Cancel/Replace Request ......................................................................................... 29
6.2.3 Order Cancel Request ........................................................................................................ 32
6.2.4 Order Cancel Reject ........................................................................................................... 32
6.2.5 Order Status Request ......................................................................................................... 34
6.2.6 Execution Report ................................................................................................................ 34
6.3 Workflows ..................................................................................................................................... 39
6.3.1 Enter Order ......................................................................................................................... 39
6.3.2 Enter Order (match)............................................................................................................ 40
6.3.3 Cancel Order ...................................................................................................................... 41
6.3.4 Cancel Replace Order ........................................................................................................ 42
7 News ................................................................................................................................................ 43
7.1 Business Message Types ............................................................................................................. 43
7.2 Message Details ........................................................................................................................... 43
7.2.1 News Message ................................................................................................................... 43
8 Security List ..................................................................................................................................... 44
8.1 Business Message Types ............................................................................................................. 44
8.1.1 Maturity Rolling Prompt ...................................................................................................... 44
8.2 Message Details ........................................................................................................................... 45
8.2.1 Security List Request.......................................................................................................... 45
8.2.2 Security List ........................................................................................................................ 45
9 Security Status ................................................................................................................................ 48
9.1 Business Message Types ............................................................................................................. 48
9.2 Message Details ........................................................................................................................... 48
9.2.1 Security Status Request ..................................................................................................... 48
9.2.2 Security Status ................................................................................................................... 49
10 Drop Copy ....................................................................................................................................... 51
10.1 Business Message Types ............................................................................................................. 51
10.2 Message Details ........................................................................................................................... 52
10.2.1 Trade Capture Report Request .......................................................................................... 52
10.2.2 Trade Capture Report Request Ack ................................................................................... 53
10.2.3 Trade Capture Report......................................................................................................... 53
10.3 Workflows ..................................................................................................................................... 57
11 Market Data ..................................................................................................................................... 58

Page 3
  Cinnober Financial Technology AB

11.1 Business Message Types ............................................................................................................. 58

11.1.1 Market Data Request.......................................................................................................... 59
11.1.2 Market Data Message Price Depth .................................................................................... 60
11.1.3 Market Data Messages # of Messages .............................................................................. 60
11.1.4 End of Day Information ....................................................................................................... 63
11.1.5 Rolling Prompts .................................................................................................................. 63
11.1.6 Trade Replay ...................................................................................................................... 63
11.1.7 Replay of Indicative Quotes ............................................................................................... 64
11.1.8 Replay of prices from MOIC ............................................................................................... 64
11.1.9 Replay of Reports ............................................................................................................... 65
11.1.10 Rules for handling Market Data Messages ........................................................................ 65
11.2 Message Details ........................................................................................................................... 66
11.2.1 Market Data Request.......................................................................................................... 66
11.2.2 Market Data Request Reject .............................................................................................. 71
11.2.3 Market Data – Snapshot/Full Refresh ................................................................................ 72
11.2.4 Market Data – Incremental Refresh ................................................................................... 76
11.3 Workflows ..................................................................................................................................... 79
11.3.1 Market Data Message Sequence ....................................................................................... 79
12 General Messages .......................................................................................................................... 84
12.1 Business Message Types ............................................................................................................. 84
12.2 Message Details ........................................................................................................................... 84
12.2.1 Business Message Reject .................................................................................................. 84
13 Common Component Block ............................................................................................................ 85
13.1 Standard Header .......................................................................................................................... 85
13.2 Standard Trailer ............................................................................................................................ 86
13.3 Instrument Component Block ....................................................................................................... 86
13.4 Parties Block ................................................................................................................................. 88
14 LME Specific Tags .......................................................................................................................... 89
15 Instrument Block Examples ............................................................................................................. 94

Page 4
  Cinnober Financial Technology AB

1 Document Overview
This document describes the new functionality in FIX for LMEselect 9, as well as the existing
messages in FIX.

The purpose of this document is to clearly describe the functionality in FIX for LMEselect 9 regarding
syntax and semantics.

The LMEselect 9 system implements a subset of FIX 4.4.

1.1 Intended Audience

* To anybody at the LME whom it may concern.
* ISV FIX developers.
* Market data vendors.

1.2 Related Documents

* FIX 4.4 protocol, version 4.4 – 18/06/2003 (see http://fixprotocol.org/specifications/).

Page 5
  Cinnober Financial Technology AB

2 About This Document

2.1 Revision History

Revision History

• Removed End-of-Day from section: 9.2.2

• Amendment to Parties Block in sections: 6.2.1 and 6.2.2
• Section 6.1.2 updated with additions of MAF, Premiums, Steel Rebar and Steel Scrap to the
table.

2.2 Terms & Acronyms

Term/Acronym Description

T Select FIX Trader

MD Select FIX Market Data User

DC Select FIX Drop Copy User

MDV Select FIX Market Data Vendor

3 Introduction

3.1 Reading Instructions

The document describes:

• FIX Session layer: A section describing the FIX session layer and supported session level
messages.

• Business Layer Introduction: A section describing the user interaction and the main
workflows.

• Order Management: A section describing how to enter orders. Subsections include:

1) Price Units
2) CFI Code
3) Maturity Dates
4) Execution Reports for Multi-Leg Contracts
5) ExecID

Page 6
  Cinnober Financial Technology AB

• News: A section describing the News functionality.

• Security List: A section describing Security List.

• Security Status: A section describing Security Status.

• Drop Copy: A section describing the different messages that are used for Drop Copy.

• Market Data: A section describing how to use the Market Data functionality. Subsections
include:
1) Market Data Request
2) Market Data Message Price Depth
3) Market Data Messages # of Messages
4) Trade replay

• General Messages: A section describing general application messages.

• Common Component Blocks: A list of the common blocks of information used in

messages.•

• LME Specific Tags: A list of the LME Specific Tags used in Select 7.

• Appendix A: Instrument Block Examples.

4 FIX Session Layer

4.1 FIX Session Establishment

A FIX session is established by sending a Logon message. The FIX session is established between
two parties; (a) the sender and (b) the target. These are represented by the following tags in the
Standard Message Header:

• SenderCompID (tag 49) – the party initiating the session.

• TargetCompID (tag56) – the acceptor of the session as per configuration.

• The FIX session is always initiated by the FIX client and accepted by the FIX server.

4.2 Start of Day/End of Day Procedures

A FIX session can last forever, or until:

• A login message that specifies the sequence numbers should be reset, using
ResetSeqNumFlag=Y (tag 141)

• A SequenceReset message is sent by either side of the FIX session.

• As defined by the market place.

4.3 Reject Handling

This section describes FIX reject handling.

Page 7
  Cinnober Financial Technology AB

The Reject message (MsgType = 3) is used when a message is received but cannot be properly
1
processed due to a session level rule violation. Some examples :

• A message without a mandatory tag.

• A message with an incorrect value for a specific tag.

• A tag without a value.

• Unknown message type.

• A tag which appears more than once.

If an application-level message passes the syntax checking on the FIX Session level it should then
be processed at the business-level. If this process detects an error condition at business-level then a
reject should be issued. Many business-level messages have specific “reject” messages which
should be used. Business-level messages lacking specific “reject” messages should use the
Business Message Reject message (MsgType = j).
The exceptions for the specific business-level reject message are:

• In the event a business message is received and fulfills the session-level rules, the message
cannot be communicated to the business-level processing system. In this situation a
Business Message Reject with BusinessRejectReason = “Application not available at this
time” can be issued.

• In the event a valid business message is received and fulfills session-level rules, the
message type is not supported by the recipient. In this situation a Business Message Reject
message with BusinessRejectReason= “Unsupported Message Type” can be issued.

• In the event a business message is received and fulfills session level-rules, but lacks a field
conditionally required by the FIX specification. However, a Business Message Reject
message must NOT be used to enforce proprietary rules more restrictive than those explicit
in the FIX specification. For example, requiring a Trade Capture Report to contain a
TradeRequestID which the FIX specification considers to be optional.

4.4 Authorization

All FIX Sessions are subject to authorisation. When the FIX server receives a Logon message at
connection start-up, the session is authorised using:

• SenderCompID (tag 49). This is the session identifier together with the TargetCompID (tag
56).

• Username (tag 553). Must contain the user ID assigned by the LME.

• Password (tag 554). Must contain the password assigned by the LME.

4.5 Message Details

The following sections cover all supported Session Messages.

1
All supported FIX Session level reject reasons are presented in section 4.5.6

Page 8
  Cinnober Financial Technology AB

FIX Message Name Type Direction

Logon A In/Out

Heartbeat
0 In/Out

Test Request 1 In/Out

Resend Request 2 In/Out

Reject 3 Out

Sequence Reset 4 In/Out

Logout 5 In/Out

4.5.1 Logon

The first messages exchanged in a FIX session are the Logon request and the Logon response. The
main purposes of the Logon request and response are:

• To authenticate the client.

• To agree on the sequence numbers.

The session initiator waits to begin sending application messages until it receives the Logon
response.
The FIX server requires an encrypted password. In order to accomplish an encryption of the
password, additional information is conveyed using the RawData (tag 96) field and the
RawDataLength (tag 95) which is required. Currently a single entity/subfield is packed into the
RawData field.
A varying number is used to further scramble the password and to make the encrypted password to
be different each time a logon occurs. This number:
1) Is an integer number.
2) Has a value which is the current system time in milliseconds expressed in the GMT time.
3) Is higher than the system time in milliseconds the previous midnight in GMT time.
4) Is lower than the system time in milliseconds the following midnight in GMT time.
5) Has a higher value than the number used in the previous Logon request.0)
A letter identifies subfields. A colon delimits a subfield identifier from a subfield value. The delimiter
for the client random number is ‘m’. A typical RawData value would be m:1065641126118 from a
client logging on to the first version of the FIX server.
If the logon request is rejected, a logout message is sent back with the reason for the rejection in the
Text (tag 58) field and the TCP/IP session is terminated by the FIX server.

Page 9
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

Standard Header Y MsgType= A. Component block, see

section 13.1

98 EncryptMethod Method for encryption.

Y
Valid value is: 0 = None

108 HeartBtInt Y Heartbeat interval (seconds). Must be

greater than zero.

95 RawDataLength N Number of bytes in raw data field.

Required on incoming Logon
messages from the client.

96 RawData N Unformatted raw data. Required on

incoming Logon messages from the
client.

141 ResetSeqNumFlag N Indicates that both sides of the FIX

session should reset sequence
numbers. Must always be set to Y for
MIX MD. If omitted default value is N.

789 NextExpectedMsgSeqNum N Next expected MsgSeqNum (tag 34)

value to be received. This field is
required when reconnecting intraday or
logging on after a failover.

553 Username N Must contain the user ID assigned by

the LME. SenderCompID must be set
to this value.

554 Password N Must contain the password assigned

by the LME.

Standard Trailer Y Component block, see section 13.2

Password Encryption

The following entities make up the encrypted password:

1. A hash pattern applied on the source password.

Page 10
  Cinnober Financial Technology AB

2. The 32-byte fax key, a field from the user’s LMEselect account that is copied beside the
protocol, probably by fax or email.
3. The "HmacSHA1" encryption algorithm.
4. An 8-byte increasing number generated by the client.0.
Java and C/C++ source codes to create the hash pattern can be found on LME’s member site,
http://www.lme.com/login/. The LME may assist third-party developers in finding the required source
code in Java and C that implements the “HmacSHA1” encryption algorithm.

4.5.2 Logon after failover and reconnect

When logging on after a failover or reconnect, the field NextExpectedMsgSeqNum (tag 789) must be
provided in the Logon message (this does not apply to the Market Data server since this is a
concurrent server). By receiving this next expected sequence number we can compare it to the last
replicated sequence number and calculate the difference from the last replicated messages -
LastMsgSeqNumProcessed (tag 369) field to the NextExpectedMsgSeqNum (tag 789) provided by
the client. The sequence number which the FIX server last processed will be used to populate the
NextExpectedMsgSeqNum (tag 789) in the Logon response.
After logging on after a failover or reconnect the client will be expected to resend the messages
which were not replicated to the secondary server as specified by the NextExpectedMsgSeqNum
(tag 789). These resent messages will be used to synchronize the cache in the FIX server. This
Logon behaviour is documented in the FIX protocol specification under the heading of “Logon
Message NextExpectedMsgSeqNum Processing” as an optional method introduced in FIX 4.4.
Once the FIX server has synchronized with the back-end, any outgoing messages resulting from the
synchronization will be sent to the client with the PossResend (tag 97) field set to ‘true’. In this
manner the client will receive messages that may have been received previously when the secondary
server synchronizes its caches, but no message will be lost.
If the client should ask for a resend of messages not replicated in a fail over, these will be replied to
with a gap fill message (SequenceReset (4) with the GapFillFlag (tag 123) set to ‘true’). By
responding with a gap fill we do not break protocol. Additionally, sending all messages that could
possibly have been lost with the PossResend (tag 97) field set we can guarantee that all messages
are sent to the client.
Workflow for logging-on after a failover

Msg MsgSeqNum (34) NextExpectedMsgSeqNum (789) Description

-> Logon 1 - First Logon from client to

FSOE1 (FIX Order Enter
primary).

<- 1
- Reply from server.
Logon

-> New 2 - This message is not

Order replicated to the secondary
Single site.

Page 11
  Cinnober Financial Technology AB

Msg MsgSeqNum (34) NextExpectedMsgSeqNum (789) Description

<- 2 - -
Execution
Report

- - - Failover from FSOE1 to

FSOE1S (FIX Order Entry
secondary).

-> Logon 3 3 Client logs on to FSOE1S.

<- Logon 3 2 Reply from server.

-> New 2 - The client resends this

Order message.
Single

-> 3 - -
Sequence
Reset

<- 4 - Sent with PossResend

Execution (tag97) = Y
Report

Example of a failover with one lost NewOrderSingle

In this scenario, the client inserts 5 NewOrderSingles to the primary site and for some reason the last
message is not replicated to the secondary site. After this the failover takes place and FSOE1S takes
over. After the logon to FSOE1S, the client resends all the messages with MsgSeqNum more or
equal to the NextExpectedMsgSeqNum (6) in the logon response from FSOE1S (which in this case
would be the last NewOrderSingle with MsgSeqNum = 6 and a SequenceReset message as a
GapFillMessage instead of the Logon message with MsgSeqNum = 7). All the resend messages
have PossDupFlag = Y. FSOE1S will send an ExecutionReport with PossResend = Y in response to
the resending of the last NewOrderSingle.

Seq Num Server/Client Message Description

Type

2 Client D Insert Order

Page 12
  Cinnober Financial Technology AB

Seq Num Server/Client Message Description

Type

2 Server
8 Ack

3 Client D -

3 Server 8 -

4 Client D -

4 Server 8 -

5 Client D -

5 Server 8 -

6 Client D -

6 Server 8 -

Failover from FSOE1 to FSOE1S

7 Client A 789=7

7 Server A 789=6 (the secondary server didn’t receive the last

order)

6 Client D 43=Y (resend of order)

7 Client 4 36=8 (sequence reset)

8 Server 8 97=Y

4.5.3 Heartbeat

During periods of message inactivity, FIX applications will generate Heartbeat messages at regular
time intervals. The heartbeat monitors the status of the communication link and identifies incoming
sequence number gaps.
When logging on, the client requests a heartbeat interval, using the HeartBtInt tag (see the logon
message). Heartbeats must be sent in both directions:

• The FIX server will send Heartbeat requests at the requested interval, unless other
messages are sent.

Page 13
  Cinnober Financial Technology AB

• The FIX Client must send Heartbeat requests at the requested interval, unless other
messages are sent.

Tag Field Name Req’d Comments

- Standard Header Y MsgType = 0. Component block, see section 13.1

112 TestReqID
N Required when the heartbeat is a result of a Test
Request (MsgType = 1) message.

- Standard Trailer Y Component block, see section 13.2

4.5.4 Test Request

The FIX server supports Test Requests in both directions. Client Test Requests are responded to
with Heartbeats conveying the test request ID. The FIX server may send Test Requests in order to
verify the reception of a sequence of outbound messages, confirming that the FIX client has captured
the messages sent.
The grace period after the FIX server has sent a Test Request is 1.2 heartbeats. For example, if the
heartbeat interval is 30 seconds, the grace period will be 36 seconds before the server disconnects
the client if the client does not reply to the Test Request message.

Tag Field Name Req’d Comments

- Standard Header Y MsgType = 1. Component block, see section 13.1

112 TestReqID
Y The value will be returned in the resulting Heartbeat.

- Standard Trailer Y Component block, see section 13.2

4.5.5 Resend Request

The FIX server supports client Resend Requests and may issue a Resend Request as a
consequence of the Logon sequence number negotiation. After the initial negotiation, there should be
no reason for requesting retransmissions because the underlying protocol, TCP/IP, manages
retransmissions. It is recommended that clients use an EndSeqNo value of 0, indicating all messages
during retransmission are to be resent.

Tag Field Name Req’d Comments

Standard Header Y MsgType = 2. Component block, see section 13.1

7 BeginSeqNo
Y Message sequence number of the first message in the
range to be resent.

Page 14
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

16 EndSeqNo Y Message sequence number of the last message in the

range to be resent. If the request is for all messages
subsequent to a particular message, the EndSeqNo field
should be set to 0 (representing infinity).

Standard Trailer Y Component block, see section 13.2

4.5.6 Reject

See Section 4.2 for usage.

Tag Field Name Req’d Comments

Standard Header Y MsgType = 3. Component block, see section 13.1

45 RefSeqNum
Y MsgSeqNum of rejected message.

371 RefTagID N The tag number of the FIX field being referenced.

372 RefMsgType N The MsgType of the FIX message being referenced.

Code to identify the reason for a session-level Reject

373 SessionRejectReason N
message.
Valid values:
0 = Invalid tag number
1 = Required tag missing
2 = Tag not defined for this message type
3 = Undefined tag
4 = Tag specified without a value
5 = Value is incorrect (out of range) for this tag
6 = Incorrect data format for value
7 = Decryption problem
9 = CompID problem
10 = SendingTime accuracy problem
11 = Invalid MsgType
13 = Tag appears more than once
14 = Tag specified out of required order
15 = Repeating group fields out of order
16 = Incorrect NumInGroup count for repeating group
17 = Non “data” value includes field delimiter (SOH
character)
98 = Service not available at this time
99 = Other

Page 15
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

Standard Header Y MsgType = 3. Component block, see section 13.1

58 Text N Where possible, message to explain reason for

rejection.

Standard Trailer Y Component block, see section 13.2

4.5.7 Sequence Reset

The FIX server supports both Gap Fill mode and Reset mode.
Gap Fill mode is used in response to a Resent Request when one or more messages must be
skipped over.
Reset mode involves specifying an arbitrary higher new sequence number to be expected by the
receiver of the Sequence Reset. It is used to re-establish a FIX session after an unrecoverable
application failure.

Tag Field Name Req’d Comments

Standard Header Y MsgType = 4. Component block, see section 13.1

123 GapFillFlag Indicator of Gap Fill mode.

N
Valid values:
Y = Gap Field message, MsgSeqNum (tag34) field
valid.
N = Sequence Reset, ignore MsgSeqNum (tag 34).
If omitted default value is N.

36 NewSeqNo Y The new sequence number to be expected by the

received.

Standard Trailer Y Component block, see section 13.2

4.5.8 Logout
The Logout message initiates or confirms the termination of a FIX session. FIX clients should
terminate their sessions gracefully by logging out.
When a user logs out from LMEselect then all orders will be inactivated except for GTC orders. If the
user disconnects from LMEselect without logging out, all orders will be inactivated. The orders need
to be activated after a reconnect.

Page 16
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

Standard Header Y MsgType = 5. Component block, see section 13.1

58 Text
N Additional description of message.

Standard Trailer Y Component block, see section 13.2

4.5.9 Disable Users

If a FIX user is disabled by LME Helpdesk while logged in then a Logout message will be sent to the
user and the session will be disconnected.

5 Business Layer Introduction

5.1 User Interaction

There are three types of FIX users in the LMEselect system.

• FIX Traders (FIX OE) are allowed to enter orders and receive execution reports.

• FIX Market Data users (FIX MD) are allowed to issue market data requests, i.e. subscribe to
market data.

• FIX Drop Copy users (FIX DC) are allowed to connect to FIX Drop Copy server and receive
Trade Capture Reports and Execution Reports from both the FIX side as well as from the
GUI, and send Trade Capture Report Requests.
FIX Traders are allowed to enter orders, receive execution reports and query for a Security List. FIX
Market Data users are allowed to issue market data requests, i.e. subscribe to market data, query for
a Security List and use the Security Status functionality. FIX Drop Copy users are able to connect to
FIX Drop Copy server and receive Trade Capture Reports and Execution Reports, and send Trade
Capture Report Requests to query for trade.
The scenarios shown in Figure 1 and Figure 2 assume that member B has a FIX Market Data user
with an active subscription on bid and ask orders, i.e. have issued a Market Data Request for bid and
ask.
Order events are handled as below:

Page 17
  Cinnober Financial Technology AB

Figure 1

Scenario 1:

1. Member A places an order via GUI.

2. Member A GUI and Member B GUI receive the order via broadcast.
3. Member B FIX-MD receives market data (order book) via FIX Market Data message.

Scenario 2:

1. Member A places an order via FIX.

2. Member A GUI and Member B GUI receive the order via broadcast and Member A FIX-
Trader receives order via FIX Execution Report message.

3. Member B FIX-MD receives market data (order book) via FIX Market Data message.•

Page 18
  Cinnober Financial Technology AB

Trade events are handled as below:

Figure 2

Scenario 1:

1. Member A places an order via GUI.

2. Member A GUI and Member B GUI receive the order via broadcast and Member A FIX-DC
receives order via FIX Execution Report message
3. Member B FIX-MD receives order via FIX Market Data message.
4. Member B GUI enters an order that match the Member A Order.
5. Member A GUI and Member B GUI receive the trade via broadcast.
6. Member B FIX-MD receives the current order book via FIX Market Data message.
7. Member A FIX-DC receives the trade via FIX Execution Report.
8. Member B FIX-MD receives the trade via FIX Market Data message.

Scenario 2:
1. Member A places an order via FIX.
2. Member A GUI and Member B GUI receives the order via broadcast, Member A FIX-Trader
receives the order via FIX Execution Report message.
3. Member B FIX-MD receives order via FIX Market Data message.
4. Member B GUI enters an order that match the Member A Order.
5. Member A GUI and Member B GUI receive the trade via broadcast.
6. Member B FIX-MD receives the current order book via FIX Market Data message.

Page 19
  Cinnober Financial Technology AB

7. Member A FIX-Trader receives the trade via FIX Execution Report.

8. Member B FIX-MD receives the trade via FIX Market Data message.

6 Order Management

6.1 Business Message Types

The FIX server supports the message types described in the following table.

FIX Message Name Type Dir Comment Authorised User

Type

New Order – Single D In Used to enter orders into the T

system.

Order G In
Used to change the parameters of T
Cancel/Replace
Request an existing order.

Order Cancel Request F In Used to cancel own orders. T

Order Cancel Reject 9 Out Response if the Order Cancel T

Request was rejected.

Order Status Request H In Used to request the current status T

for own orders.

Used for the following purposes:

Execution Report 8 Out T + DC
• Confirm the receipt of an
order.

• Confirm changes to an
existing order.

• Relay order status

information.

• Relay fill information on

working orders.

• Reject orders.

Page 20
  Cinnober Financial Technology AB

6.1.1 Price Units

Prices
Different contract types use different price types (price, tag 44). The price types differ both in their
price unit and their meaning. For carry orders, the order price is the net difference in trading price
between the buy leg and sell leg. For metal option and metal option strips, the order price is
expressed in volatility. If the order is matched, this price is converted into to a premium in USD, using
the Black76 model.

Contract Type Price Type Price Unit

Metal single outright Outright price USD

Metal average
Outright price USD
outright

Metal carry Net price USD

Metal option Volatility %

Metal option strip Volatility %

Metal TAPO Premium USD

Index single outright Outright price USD

Index carry Net price USD

Index option Premium USD

Net Prices for Carry Contracts

At the LME, the net prices for carry contracts have different names depending on the slope of the
time-price curve they describe:

• Contango prices – when the price of the leg far away in time is higher than the price of the
leg nearer in time. In FIX, this type of price is represented by a negative price.

• Backwardation prices - when the price of the leg far away in time is lower than the price of
the leg nearer in time. In FIX, this type of price is represented by a positive price.

• Level – when the price of both legs should be equal. This is represented by a price of zero.

6.1.2 CFI Code

The ISO 10962 Classification of Financial Instruments standard defines a standard for naming
different classes of securities. The FIX protocol uses this standard.
The FIX server converts CFI codes (tag 461) to LME contract types according to the table below:

Page 21
  Cinnober Financial Technology AB

Code Description Used for

FCEPS Future, Commodity, Extraction, Physical, Single outright futures, Monthly

Standardized Average Futures, Premiums

FFICS Future, Financial, Index, Cash, Index futures.

Standardized

OPAFPS Option, Put, American, Future, Physical, Metal future put options.
Standardized

OCAFPS Option, Call, American, Future, Physical, Metal future call options.
Standardized

OPXTCS Option, Put, Commodity, Cash, Metal TAPO puts.

Standardized

OCXTCS Option, Call, Commodity, Cash, Metal TAPO calls.

Standardized

OPEICS Option, Put, European, Index, Cash, Index put options.

Standardized

OCEICS Option, Call, European, Index, Cash, Index call options.

Standardized

FCECS Future, Commodity, Extraction, Cash, LMEmini, Steel Scrap and Steel
Standardized Rebar

* Please note there are no Index TAPO contracts.

6.1.3 Maturity Dates

Futures
An LME future is defined by a symbol and a maturity date, the prompt date. There are three different
types of prompt dates for futures (PromptType, tag 10004):
* Rolling prompt dates – these prompt dates are relative to the current trading day. When trades in
these contracts are sent to clearing, the date is “frozen” into a calendar date. There are three rolling
prompts (MaturityRollingPrompt, tag 10000, and LegMaturityRollingPrompt, tag 10002):
1) 3M (Three months) – this prompt date represents the date three months from today.
2) C (Cash) – this prompt date represents the day after tomorrow.
3) TOM (Tomorrow) – this prompt date represents tomorrow.

Page 22
  Cinnober Financial Technology AB

* Single prompt dates (MaturityDate, tag 541) – these prompt dates are calendar dates, written in
the format YYYYMMDD, where YYYY is the year, MM is the month (01-12) and DD is the day
(01-31). The LME uses the concept of “Monthly”, “Weekly” and “Daily” contracts, but all these
contract types represent one single prompt date and no difference is being made between them
rd
in this FIX specification. (For “Monthly” contracts, the prompt date is the 3 Wednesday in the
month, for “Weekly” contracts, the prompt is the Wednesday in the week.)
* Average prompt dates (MaturityAveragePrompt, tag 10001) – these prompt dates represent
several calendar dates. There are three types of average prompts:
1) Quarterly prompts – These are written NQYY, where N is 1, 2, 3 or 4, and YY are the two last
figures in the year. A quarterly prompt represents three calendar dates, namely the monthly
rd
contracts (i.e. the 3 Wednesdays in the months) in the quarter.
2) Half-year prompts – These are written NHYY where N is 1 or 2, and YY are the two last
figures in the year. A half-year prompt represents six calendar dates, namely the monthly
rd
contracts (i.e. the 3 Wednesdays in the months) in the half-year.
3) Full-year prompts – These are written 1YY’Y’ where Y’Y’ are the two last figures in the year.
A full-year prompt represents twelve calendar dates, namely the monthly contracts (i.e. the
rd
3 Wednesdays in the months) in the year.
To know what prompt dates that are available, it is necessary to have access to an LME trading
calendar. A quick and incomplete summary of the trading calendar is:
For a metal and steel 3M and C always exist and TOM almost always exists. There exists one
prompt day per business day between the TOM and the 3M contract, thereafter a prompt day every
rd
Wednesday for 3 months, and then prompt days the 3 Wednesday in the month for a number of
months, depending on the underlying commodity. There exist average contracts that span the
months after the 3M contract.
nd
For the index, there exists one prompt day every 2 Wednesday in the month for 12 months. There
are no rolling prompts and no average prompts.
rd
For LMEMini, there exist one prompt every 3 Wednesday in the month for 12 months. There are no
rolling prompts.
For LMEswaps, there is one prompt on the last working day of each month. (This is actually the last
tradable day rather than the LME Rulebook definition of the settlement date.)

Options
An option is defined by a symbol, an option type, a strike price and an expiration date. There are two
types of expiration dates:

• Single expiration dates (MaturityDate, tag 541) – these are calendar dates, written in the
format YYYYMMDD, where YYYY is the year, mm is the month (01-12) and DD is the day
(01-31). For metals, there is one expiration date per month: the first Wednesday in the
month. For the index, the expiration date is the second Wednesday in the month. For both
symbols, the expiration date is rolled forward one day if the expiration date is a non-business
day. Consult an LME trading calendar for exact rules for expiration dates.

• Average expiration dates (MaturityAveragePrompt, tag 10001) - these expiration dates

represent several calendar dates. They are only available for metals. There are three types
of average dates:

Page 23
  Cinnober Financial Technology AB

1) Quarterly expiration dates – These are written NQYY, where N is 1, 2, 3 or 4, and YY are the
st
two last figures in the year. A quarterly date represents three calendar dates, namely the 1
Wednesdays in the months in the quarter.
2) Half-year expiration dates – These are written NHYY where N is 1 or 2, and YY are the two
st
last figures in the year. A half-year date represents six calendar dates, namely the 1
Wednesdays in the months in the half-year.
3) Full-year expiration dates – These are written 1YY’Y’ where Y’Y’ are the two last figures in
st
the year. A full-year date represents twelve calendar dates, namely the 1 Wednesdays in
the months in the year.

TAPOS
A TAPO is defined by a symbol (only metals), an option type, a strike price and an expiration date.
For TAPOS, the only allowed expiration date is the single expiration date in format YYYYMMDD.
There is one expiration date per month: the last trading day of the month.

6.1.4 Execution Reports for Multi-Leg Contracts

For some instruments, an execution report representing a trade will contain several trade legs,
although the order insert transaction only contained one instrument leg. The LastPx (tag 31) and
LastQty (tag 32) fields are still well-defined, but the trade legs contain additional information, e.g. on
how a carry net price was converted into trade prices in the contracts spanned by the carry. This
situation occurs for:

• Carry contracts. The legs in the execution report represent the contracts spanned by the
carry. The LastPx represents the net price for the entire carry; the leg prices represent the
trade prices in the contracts.

• Average contracts. The legs in the execution report represent the monthly contracts that the
average contract (quarters, half-year or whole-year) defines.

• Metal options. The order entry transaction contains a price expressed in volatility. The
trading system will convert this into a price expressed in dollars and possibly create a hedge
trade in the future that the option is based on. The execution report will contain one or two
legs: leg 1 defines the price in dollars, leg 2 the price and quantity of the hedge trade.

• Metal option strips. As for the metal options, the legs in the execution report represent the
dollar price and hedge trades for all legs in the option strip. Since the strip represents a
number of monthly contracts (cf. average contracts), the number of legs may become twice
the number of legs in the strip. In the case of a yearly strip, e.g. 1Y05 that was hedged by the
system, the execution report will contain 24 legs. If no hedge trades were made, the report
will contain 12 legs.

6.1.5 ExecID

The ExecID (tag 17) is a unique identifier of Execution Report messages. In LMEselect 9 it will have
the following format when representing a trade:
TA-<underlying>-<tradeDate>-<sequence number>-<char>

Page 24
  Cinnober Financial Technology AB

The sequence number is defined as data type long and could theoretically be up to 19 characters.
For example, a trade in underlying ‘AA’ on 9 Feb 2010 will have an ExecID that looks something like
this:
TA-AA-20100209-000049-A for one side and
TA-AA-20100209-000049-B for the other side
Example of ExecID for a carry order:
ON-AA-20091015-000001-11708

6.1.6 OrderID

The OrderID (tag 37) is a unique identifier for an order assigned by the Select system.
Example of OrderID for a carry trade:
ON-AA-20091015-000001

6.1.7 Stop Loss Order

The following tags are required to define a stop loss order:

Tag Field Name Req’d Comments

4 = StopLimit
40 Order type Y
It defines the order type to be a stop
loss, rather than 40=2 (Limit) as for
ordinary limit orders.

99 StopPx Yes; for stop loss The trigger price.

orders

6.2 Message Details

6.2.1 New Order – Single

Tag Field Name Req’d Comments

Standard Header Y MsgType = D. Component block, see

section 13.1

11 ClOrdID Y Unique identifier set by the entering

firm.

If this field is used it must be set to:

21 HandlInst N

Page 25
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

1 = Automated execution order,

private, no Broker intervention.

Component block, see section 13.4

Parties Y

Valid values:
18 ExecInst N
S = Suspend (order is inactivated,
removed from public view and not
available for matching. It is, however,
retained by the trading system and
may be activated later).
2 = Work (order is active, viewable
and available for matching).
Absence of this field indicates Work.
An inactive order can be reactivated
again by sending an
OrderCancelReplaceRequest
message with ExecInst (tag 18) =
Work (2).

111 MaxFloor N Visible order quantity used for iceberg

orders.

Instrument Y Component block, see section 13.3

Valid values:
54 Side Y
1 = Buy
2 = Sell

60 TransactTime Y Time this order request was initiated

by the trader. Format is YYYYMMDD-
HH:mm:ss.SSS in 24H.

38 OrderQty Y Order quantity.

Valid value is:

40 OrdType Y
2 = Limit
4 = Stop Limit, defines the order type
to be a stop loss

44 Price Y For orders in carry contracts, a

“contango” price is expressed as a
negative price, and a “backwardation”

Page 26
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

price as a positive price.

Valid values:
59 TimeInForce N
0 = Day
1 = Good ‘til Cancel
3 = Immediate or Cancel
6 = Good ‘til Date
Good ‘til Cancel and Good ‘til Date
are only available for Cash and 3M
outright contracts.
Absence of this field indicates Day.

Conditionally required if TimeInForce

126 ExpireTime N
= Good ‘Til Date and ExpireTime is
not specified.
Format is YYYYMMDD-HH:mm:ss in
24H. The date must be the current
day.

Conditionally required if TimeInForce

432 ExpireDate N
= Good ‘til Date and ExpireTime is
not specified.
Format is YYYYMMDD.

99 StopPx N The Stop loss trigger price. The tag is

mandatory for Stop loss orders.

58 Text Y The value supplied in this field needs

to be for a valid link to the trader’s
account. Max. 40 characters.

389 DiscretionOffsetValue N Number of ticks. May be a negative

value.

If this field is used it must be set to:

841 DiscretionMoveType N
1 = Fixed on Discretionary orders.
The default value, however, is 1 for
discretionary orders so this field can
be omitted.

Indicates if the order is entered either

529 OrderRestrictions Y
by an algo trader or a human.
Valid values:
D = Non-algorithmic (human)

Page 27
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

E = Algorithmic (algo)

ISO Country Code of the branch

10048 InvestmentDecisionCountry N
responsible for the person making
the investment decision. This field
will be used only if LME performs
Transaction Reporting.

10049 ExecutionDecisionCountry N ISO Country Code of the branch

responsible for the person making the
execution decision. This field will be
used only if LME performs
Transaction Reporting.

Indicates if the trader has a direct

10050 DEA Y
electronic access.
Valid values:
Y = The trader has direct electronic
access
N = The trader does not have direct
electronic access.

Indicates the type of trading capacity.

10051 TradingCapacity Y
Valid values:
1 = DEAL (Dealing on own account)
2 = MTCH (Matched principal)
3 = AOTC (Any other capacity)

Specifies the type of account

581 AccountType Y
associated with the order.
Valid values:
1 = Client ISA
2 = House
3 = Client OSA
7 = Gross OSA

Standard Trailer Y Component block, see section 13.2

If the order is accepted by the trading system, an Execution Report message with ExecType = 0
(New) will be sent. Note that no Pending New message will be sent.
If the order is rejected by the trading system, an Execution Report message with ExecType = 8
(rejected) will be sent.

Page 28
  Cinnober Financial Technology AB

6.2.2 Order Cancel/Replace Request

Tag Field Name Req’d Comments

Standard Header Y MsgType = G. Component block, see section

13.1

37 OrderID N Select order ID.

41 OrigClOrdID Y Original order identified as the order to be

modified. It is the ID of the latest non-rejected
order (not the initial order of the day).

11 ClOrdID Y Unique identifier set by the entering firm.

If this field is used it must be set to:

21 HandlInst N
1 = Automated execution order, private, no
Broker intervention.

Parties Y Component block, see section 13.4

Valid values:
18 ExecInst N
S = Suspend (order is inactivated, removed from
public view and not available for matching. It is
however retained by the trading system and
may be activated later).
2 = Work (order is activate, viewable and
available for matching).
Absence of this field indicates Work.
An inactive order can be activated again by
sending an OrderCancelReplaceRequest
message with ExecInst (tag18) = Work (2).

111 MaxFloor N Visible order quantity used for iceberg orders.

Instrument Y Component block, see section 13.3

Must be same value as original order. Valid

54 Side Y
values:
1 = Buy
2 = Sell

60 TransactTime Y Time this order request was initiated by the

trader. Format is YYYYMMDD-HH:mm:ss.SSS in
24H.

Page 29
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

38 OrderQty Y New order quantity. Note: this is not the

LeavesQty, but the new total quantity of the
order.

The order type cannot change.

40 OrdType Y
2 = Limit
4 = Stop Limit, defines the order type to be a
stop loss

44 Price Y For an order in a carry contract, a “contango”

price is expressed as a negative price and a
“backwardation” price as positive.

Valid values:
59 TimeInForce N
0 = Day
1 = Good ‘til Cancel
3 = Immediate or Cancel
6 = Good ‘til Date
Good ‘til Cancel and Good ‘til Date are only
available for Cash and 3M outright contracts.
Absence of this field indicates Day.

Conditionally required if TimeInForce = Good ‘til

126 ExpireTime N
Date and ExpireDate is not specified.
Format is YYYYMMDD-HH:mm:ss in 24H. The
date must be the current day.

Conditionally required if TimeInForce = Good ‘til

432 ExpireDate N
Date and ExpireTime is not specified.
Format is YYYYMMDD.

99 StopPx N The Stop loss trigger price. The tag is mandatory

for Stop loss orders.

58 Text Y The value supplied in this field needs to be for a

valid link to the trader’s account. Max. 40
characters.

389 DiscretionOffsetValue N Number of ticks. May be a negative value.

If this field is used it must be set to:

841 DiscretionMoveType N
1 = Fixed on Discretionary orders.
The default value, however, is 1 for discretionary

Page 30
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

orders so this field is omitted.

Indicates if the order is entered either by an algo

529 OrderRestrictions Y
trader or a human.
Valid values:
D = Non-algorithmic (human)
E = Algorithmic (algo)

10048 InvestmentDecisionCountry N ISO Country Code of the branch responsible for

the person making the investment decision. This
field will be used only if LME performs
Transaction Reporting.

10049 ExecutionDecisionCountry N ISO Country Code of the branch responsible for

the person making the execution decision. This
field will be used only if LME performs
Transaction Reporting.

Indicates if the trader has a direct electronic

10050 DEA Y
access.
Valid values:
Y = The trader has direct electronic access
N = The trader does not have direct electronic
access.

Indicates the type of trading capacity.

10051 TradingCapacity Y
Valid values:
1 = DEAL (Dealing on own account)
2 = MTCH (Matched principal)
3 = AOTC (Any other capacity)

Specifies the type of account associated with

581 AccountType Y
the order.
Valid values:
1 = Client ISA
2 = House
3 = Client OSA
7 = Gross OSA

Standard Trailer Y Component block, see section 13.2

Page 31
  Cinnober Financial Technology AB

6.2.3 Order Cancel Request

Tag Field Name Req’d Comments

Standard Header Y MsgType = F. Component block, see section

13.1

41 OrigClOrdID Y Order identifier for the order to cancel. It is the ID

of the latest non-rejected order (not the initial
order of the day).

37 OrderID N Select order ID.

11 ClOrdID Y Unique identifier set by the entering firm.

Instrument Y Component block, see section 13.3

Valid values:
54 Side Y
1 = Buy
2 = Sell

60 TransactTime Y Time this order request was initiated. Format is

YYYYMMDD-HH:mm:ss.SSS in 24H.

38 OrderQty N Order quantity must be equal to original order

quantity. This field can also be skipped.

Standard Trailer Y Component block, see section 13.2

6.2.4 Order Cancel Reject

The Order Cancel Reject message is issued by LMEselect upon receipt of an Order Cancel Request
or Order Cancel/Replace Request message which cannot be honoured. When rejecting a
Cancel/Replace Request (or Cancel Request), the Order Cancel Reject message will provide the
ClOrdID which was specified on the Cancel/Replace Request (or Cancel Request) message for
identification, and the OrigClOrdID will be that of the last accepted order (except in the case of
CxlRejReason = “Unknown Order”). Tag 39 (OrdStatus)
If the Order Cancel Reject message is the response to an Order Cancel/Replace Request (434=2),
tag 39 (OrdStatus) is set to 0 (New).

Tag Field Name Req’d Comments

Standard Header Y MsgType = 9. Component block, see section

Page 32
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

13.1

37 OrderID N LMEselect order ID. Set by LMEselect if the

client has included this field in the Order Cancel
Request or Cancel Replace Request message.
Otherwise it will be set to “NONE”.

11 ClOrdID Y Unique identifier set by the entering firm.

41 OrigClOrdID Y Original order identified for the order to modify. It

is the ID of the latest non-rejected order (not the
initial order of the day)

Identifies current status of order.

39 OrdStatus Y
Valid values:
0 = New
1 = Partially Filled
2 = Filled
3 = Done for day
4 = Cancelled
5 = Replaced
6 = Pending Cancel
8 = Rejected
C = Expired
E = Pending Replace

Identifies the type of request that an Order

434 CxlRejResponseTo Y
Cancel Reject (9) is in response to.
Valid values:
1 = Order Cancel Request (F)
2 = Order Cancel/Replace Request (G)

Valid values:
102 CxlRejReason N
0 = Too late to cancel
1 = Unknown order
2 = Broker Option
3 = Order already in Pending Cancel or Pending
Replace Status
6 = Duplicate ClOrderID (11) received
99 = Other

58 Text N A text description of the reject reason.

Standard Trailer Y Component block, see section 13.2

Page 33
  Cinnober Financial Technology AB

6.2.5 Order Status Request

Tag Field Name Req’d Comments

Standard Header Y MsgType = H. Component block, see section

13.1

11 ClOrdID Y The ClOrdID (11) of the order whose status is

being requested.

Instrument Y Component block, see section 13.3

Valid values:
54 Side Y
1 = Buy
2 = Sell

Standard Trailer Y Component block, see section 13.2

6.2.6 Execution Report

Trades are anonymous, i.e. trades are disseminated without information regarding counter parties of
the trade. According to that requirement the FIX Execution Report will also be made anonymous.
Anonymity means that the tag 382 (NoContraBrokers) will not be present within the message.

Tag Field Name Req’d Comments

Standard Header Y MsgType = 8. Component block, see section

13.1

10022 SelectTradeID N The TradeID in the LMEselect system. Example

value TN-AA-20100331-00001.

A unique order identifier set by the trading

37 OrderID Y
system. This identifier is not changed by
cancel/replace messages; it will remain the
same for all chain of orders.
If the order is rejected the ID will be “NONE”.

11 ClOrdID Y The identifier of the message that caused this

Execution Report. Will be “NONE” for orders
entered from the trading client.

Parties N Component block, see section 13.4

41 OrigClOrdID N If this execution is an answer to a cancel/replace

Page 34
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

request, this field holds the identifier of the order

that was replaced.

17 ExecID Y Unique identifier of execution message.

19 ExecRefID N Reference identifier used with Trade Cancel and

Trade Correct execution types.

Describes the specific Execution Report.

150 ExecType Y
Valid values:
0 = New
3 = Done
4 = Cancelled
5 = Replace
6 = PendingCxl
8 = Rejected
C = Expired
D = Restated
E = PendingReplace
F = Trade
H = Trade Cancel
I = Order Status

111 MaxFloor N Visible order quantity used for iceberg orders.

Valid values:
39 OrderStatus Y
0 = New
1 = Partially Filled
2 = Filled
3 = Done for day
4 = Cancelled
5 = Replaced
6 = Pending Cancel
8 = Rejected
C = Expired
E = Pending Replace

Set if ExecType = 8 (rejected)

103 OrdRejReason N
Valid values:
0 = Other
1 = Unknown Symbol
2 = Exchange Closed
3 = Order Exceeds Limit
5 = Unknown Order
6 = Duplicate Order
13 = Incorrect Quantity

Page 35
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

15 = Unknown Account(s)

Valid values:
378 ExecRestatementReason N
1 = GT renewal / restatement

Instrument Y Component block, see section 13.3

Valid values:
54 Side Y
1 = Buy
2 = Sell

38 OrderQty Y The order quantity. Note: this is not the

remaining volume of the order. The remaining
volume is given in the LeavesQty field.

44 Price N The order price. For orders in carry contracts, a

“contango” price is expressed as a negative
price and a “backwardation price” as a positive
price.

99 StopPx N The Stop loss trigger price. The tag is mandatory

for Stop loss orders.

Valid values:
59 TimeInForce N
0 = Day
1 = Good ‘til cancel
3 = Immediate or cancel
6 = Good ‘til Date
8 = Good ‘til ring 1. Note that this value can only
be set via GUI on new orders.

Conditionally required if TimeInForce = Good ‘til

126 ExpireTime N
Date and ExpireDate is not specified.
Format is YYYYMMDD-HH:mm:ss in 24H. The
date must be the current day.

Conditionally required if TimeInForce = Good ‘til

432 ExpireDate N
Date and ExpireTime is not specified.
Format is YYYYMMDD.

Valid values:
18 ExecInst N
S = Suspend (order is inactivated, removed from
public view and not available for matching. It is,
however, retained by the trading system and

Page 36
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

may be activated later).

2 = Work (order is active, viewable and available
for matching).

32 LastQty N Set if ExecType = F (Trade). The total volume of

this trade.

31 LastPx N Set if ExecType = F (Trade). The price of this

trade.

151 LeavesQty Y The quantity is open for further execution. The

following will always be equal: OrderQty –
CumQty.

14 CumQty Y The quantity of the order that has been executed

so far.

6 AvgPx Y The average price (volume-weighted) for all the

trades this order has filled.

389 DiscretionOffsetValue N Number of ticks.

841 DiscretionMoveType N Will be set to 1 = ‘Fixed’ for Discretionary orders.

Valid value is:

842 DiscretionOffsetType N
2 = Ticks

797 CopyMsgIndicator N Indicates whether or not this message is a drop

copy of another message.

58 Text N Contains the value supplied in this field on the

order, which would have provided a valid link to
the trader’s account.

555 NoLegs N Set if ExecType = F (Trade) and the trade is

done in a multi-leg carry, an average contract,
metal options or metal option strips. (See section
“Multi-leg contracts” for details).

LegSymbol N A two-letter string describing the metal or index

600 for this leg. This is the start tag for the
representing group and is mandatory if NoLegs >

Page 37
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

0.

LegCFICode N Describes the type of contract this leg

608 represents.

LegPromptType N Describes what kind of prompt type that this leg

10005 uses.

Required if LegPromptType=‘R’.
LegMaturityRollingPrompt N
Valid values:
10002
TOM = Tomorrow
C = Cash
3M = 3 Months

LegMaturityDate N Mandatory if LegPromptTypre=“S”. Used for

611 daily, weekly and monthly contracts. Represents
the prompt date for futures, plus expiration date
for options and TAPO’s.

LegSide N Represent whether the trade in the leg was a

624 buy or sell.

LegLastQty N Represents the trade quantity for this leg.

10003

LegLastPx N Represents the trade price for this leg.

637

Indicates if the order is entered either by an algo

529 OrderRestrictions N
trader or a human.
Valid values:
D = Non-algorithmic (human)
E = Algorithmic (algo)

10048 InvestmentDecisionCountry N ISO Country Code of the branch responsible for

the person making the investment decision. This
field will be used only if LME performs
Transaction Reporting.

10049 ExecutionDecisionCountry N ISO Country Code of the branch responsible for

the person making the execution decision. This
field will be used only if LME performs

Page 38
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

Transaction Reporting.

Indicates if the trader has a direct electronic

10050 DEA N
access.
Valid values:
Y = The trader has direct electronic access
N = The trader does not have direct electronic
access.

Indicates the type of trading capacity.

10051 TradingCapacity N
Valid values:
1 = DEAL (Dealing on own account)
2 = MTCH (Matched principal)
3 = AOTC (Any other capacity)

Specifies the type of account associated with

581 AccountType Y
the order.
Valid values:
1 = Client ISA
2 = House
3 = Client OSA
7 = Gross OSA

Standard Trailer Y Component block, see section 13.2

In LMEselect, busted trades will be sent out. Two messages are affected - the Execution Report and
Market Data Message. In the Execution Report a busted trade will have the tag 150 (ExecType) set
to H (Trade Cancel).

6.3 Workflows

6.3.1 Enter Order

Page 39
  Cinnober Financial Technology AB

OrdStatus
ExecType
ClOrdID
OrdID
Msg

-> 1 - 001 - -
New Order - Single

<- 2 ON-AA-20100209-000001 001 New New

Execution Report

6.3.2 Enter Order (match)

OrdStatus
ExecType
ClOrdID
OrdID
Msg

-> 1 - 002 - -
New Order - Single

<- 2 ON-AA-20100209-000002 002 New New

Execution Report

<- 3 ON-AA-20100209-000002 002 Trade Filled

Execution Report

Page 40
  Cinnober Financial Technology AB

6.3.3 Cancel Order

OrigClOrdID

ExecType
ClOrdID

OrdStatus
OrdID
Msg

-> 1 - - 003 - -
New Order - Single

<- 2 - ON-AA-20100209- 003 New New

Execution Report 000003

-> 3 003 - 004 - -

Order Cancel Req

<- 4 003 ON-AA-20100209- 004 PendingCxl Pending Cancel

Execution Report 000003

<- 5 003 ON-AA-20100209- 004 Canceled Canceled

Execution Report 000003

Page 41
  Cinnober Financial Technology AB

6.3.4 Cancel Replace Order

OrigClOrdID

OrdStatus
ExecType
ClOrdID
OrdID
Msg

-> 1 - - 005 - -
New Order - Single

<- 2 - ON-AA-20100209- 005 New New

Execution Report 000004

-> 3 005 - 006 - -

Order Cancel/Replace
Request

<- 4 005 ON-AA-20100209- 006 PendingReplace PendingRep

Execution Report 000004

<- 5 005 ON-AA-20100209- 006 Replaced New

Execution Report 000004

Page 42
  Cinnober Financial Technology AB

7 News

7.1 Business Message Types

FIX Message Type Dir. Comment Authorized

Name User Type

The news message is a general free

News B Out T + MD + DC +
format message from the exchange to the
broker. The FIX News messages MDV
implement the FIX Market Messages
requirements. For example, LME Select
Market Messages are distributed via FIX
as News messages.
Each user logged on will receive all market
messages.

7.2 Message Details

7.2.1 News Message

Tag Field Name Req’d Comments

Standard Header Y MsgType = B. Component block, see section

13.1

148 Headline Y Headline text.

33 LinesOfText Y Identifies number of lines of text body.

Text N Free text field.

58

Standard Trailer Y Component block, see section 13.2

Page 43
  Cinnober Financial Technology AB

8 Security List

8.1 Business Message Types

FIX Message Name Type Dir. Comment Authorized

User Type

Security List Request X In The Security List Request message is T + MD + DC +

used to request a list of securities MDV
from the LME that match criteria
provided on the request.

Security List Y Out The Security List is used to return a T + MD + DC +

list of securities that match criteria MDV
provided on the request or reject of
an incoming request.

8.1.1 Maturity Rolling Prompt

Valid values for MaturityRollingPrompt (tag 10000) are:

- TOM (Tomorrow) – this prompt date represents tomorrow.
- C (Cash) – this prompt date represents the day after tomorrow.
- 3M (Three months) – this prompt date represents the date three months from today.
- 15M (15 months) - the monthly contract that falls in the month 15 months from the current
month.

- 27M - the monthly contract that falls in the month 27 months from the current month.
- 63M - The monthly contract that falls in the month 63 months from the current month.
- 123M - The monthly contract that falls in the month 123 months from the current month.
- D – Day.
- W – Week.
- M – Month.
- Q – Average.
- N1 (Near 1) - The earliest monthly prompt that falls between the CASH and 3M dates.

- N2 (Near 2) - The second earliest monthly prompt that falls between the CASH and 3M
dates.
- N3 (Near 3) - The third earliest monthly prompt that falls between the CASH and 3M dates.
- F1 (Far 1) - The earliest monthly prompt that fall after the 3M date.
- F2 (Far 2) - The second earliest monthly prompt that fall after the 3M date.

Page 44
  Cinnober Financial Technology AB

- F3 (Far 3) - The third earliest monthly prompt that fall after the 3M date.

8.2 Message Details

8.2.1 Security List Request

Security list can be requested for a specific symbol or for all symbols. With a successful Security List
Request, LMEselect will send one Security List message per symbol.

Tag Field Name Req’d Comments

Standard Header Y MsgType = x. Component block, see section

13.1

320 SecurityReqID
Y Unique identifier will be returned in Security
List message.

Type of Security List Request being made.

559 SecurityListRequestType Y
Valid values:
0 = Symbol
4 = All Securities

55 Symbol N The symbol: e.g. CA. Required if

SecurityListRequestType = 0

75 TradeDate N To request securities valid for a specific trade

date (if absent current date is assumed).
Format is YYYMMDD.

Standard Trailer Y Component block, see section 13.2

8.2.2 Security List

Tag Field Name Req’d Comments

Standard Header Y MsgType = y. Component block, see section

13.1

320 SecurityReqId
Y Identifier supplied by the requestor in the
Security List Request.

322 SecurityResponseID Y Identifier for the Security List message

supplied by the server.

Page 45
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

Status of request.
560 SecurityRequestResult Y
Valid values:
0 = Valid request
1 = Invalid request
2 = No instruments found

Indicates if this message is the last message

893 LastFragment N
in a fragmented response. Only used when
‘All Securities’ were requested.
Valid values:
Y = Last message
N = Not last message

10027 NoOfMonthlyContracts N The total number of monthly contracts for the

symbol.

146 NoRelatedSym Y Specifies the number of repeating symbols

(contracts) specified.

Symbol Y The symbol: E.g. CA

55

Currency Y The currency will always be USD.

15

The type of contract: E.g. FCEPS, FFICS.

CFICode N
461 See section 6.1.2 for valid values.

Defines what prompt type that is to be used.

Prompt Type N
Valid values:
10004
S = Single Prompt Date
R = Rolling Prompt Date
A = Average Prompt Date

Required if PromptType = ‘S’. Used for daily,

Maturity Date N
weekly and monthly contracts.
541
Represents:

• Prompt date for futures

• Expiration date for options and

TAPO’s (YYYYMMDD)

Required if PromptType=‘R’ and for some

MaturityRollingPrompt N
particular prompts where PromptType=‘S’.
10000
Valid values:
TOM = Tomorrow

Page 46
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

C = Cash
3M = 3 Months
15M = 15 Months
27M = 27 Months
63M = 63 Months
123M = 123 Months
D = Day
W = Week
M = Month
Q = Average
N1 = Near 1
N2 = Near 2
N3 = Near 3
F1 = Far 1
F2 = Far 2
F3 = Far 3

RollingPromptDate N Required if prompt type = ‘R’. Used for TOM,

10011 C and 3M.

Required if PromptType=‘A’. Used for

MaturityAveragePrompt N
average contracts.
10001
Valid values are, for example, “3Q11” for
quarterly contracts, “2H12” for half-year
contracts and “1Y11” for year contracts.

IsMonthlyContract N Will be set to ‘Y’ for all monthly contracts and

10026 omitted for all other contracts.

Valid values:
SecurityStrikeType N
S = Single
10006
T = Table

NoStrikeTableRows N Number of strike rows.

10007

N Low limit for strike price.

10008 StrikeLowLimit

N Graduation for strike price.

10009 StrikeGraduation

58 Text N Free text field.

Page 47
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

Standard Trailer Y Component block, see section 13.2

9 Security Status

9.1 Business Message Types

FIX Message Type Dir. Comment Authorized

Name User Type

Security Status E In The Security Status Request message is a MD + MDV

Request request for either a snapshot, snapshot +
subscribe or unsubscribe on the security
status messages for the given underlying.
An invalid Security Status Request
message will produce a Reject message.

Security F
Out Sent as a reply to a Security Status MD + MDV
Status
Request. A Security Status message gives
the current trading state.

9.2 Message Details

9.2.1 Security Status Request

Tag Field Name Req’d Comments

Standard Header Y MsgType = e. Component block, see section

13.1

324 SecurityStatusReqID Identifier that will be returned in the Security

Y
Status messages.
Must be unique for subscriptions. E.g. If
SubscriptionRequestType = 1.
SecurityStatusReqID must be the same as the
subscription you want to unsubscribe to.

Page 48
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

55 Symbol
Y The symbol: e.g. CA

263 SubscriptionRequestType Valid values:

Y
0 = Snapshot
1 = Snapshot + Subscribe
2 = Unsubscribe

Standard Trailer
Y Component block, see section 13.2

9.2.2 Security Status

A Security Status message gives the trading state. The following states constitute the complete set of
trading states at LME:

Trading State SecurityTradingStatus (326) Text (58)

Init NotAvail (18) Init

Pre-Open
Ready (17) Pre-Open

Open Ready (17) Open

Post-Trade NotAvail (18) Post-Trade

Closed NotAvail (18) Closed

Trade halt TrdHalt (2) Trade halt

Resume (3) Trade Halt

Lift trade halt
Ready (17) Pre-OpenTH

No Session NotAvail (18) None

R1 Ready (17) Morning Ring 1

R2 Ready (17) Morning Ring 2

K1 Ready (17) Morning Kerb

R3 Ready (17) Afternoon Ring 1

R4 Ready (17) Afternoon Ring 2

Page 49
  Cinnober Financial Technology AB

Trading State SecurityTradingStatus (326) Text (58)

K2 Ready (17) Afternoon Kerb

Security Status messages are sent per contract from LMEselect. Messages are not sent out for
contracts that have not yet been created by the system. When a snapshot is requested, one Security
Status message will be sent out for each created contract for the given underlying commodity.
If the subscription request type is set to 1 (Snapshot + Subscribe), a Security Status message is sent
out when a new contract is created for the underlying.
At the LME, most contracts within the same underlying are usually in the same trading state. The
exceptions are for contracts that are running on their last trading day schedule and for contracts that
are running on a temporary trading schedule, i.e. when a state transition to a new trading state has
been manually initiated by a Service Desk user for either an underlying commodity or a contract
group within a commodity.
It is notable that Security Status messages are sent per underlying from MOIC and that only Symbol
(tag 55) is used in the Instrument component block.
For example, at 15:00 the AA future with prompt date TOM is in the CLOSED state, while the other
contracts in that underlying are in the state OPEN.

Tag Field Name Req’d Comments

Standard Header Y MsgType = f. Component block, see section

13.1

324 SecurityStatusReqID
N Unique ID, taken from the request.

Instrument
N Component block, see section 13.3

326 SecurityTradingStatus Identifies the trading status applicable to the

N
transaction.
Valid values:
2 = TrdHalt
3 = Resume
17 = Ready
18 = Not Avail

327 HaltReason Denotes the reason for the Trading Halt.

N
Valid values:
X = Equipment Changeover
M = Additional Information

58 Text
N Contains the name of the trading state.

10037 MDEntrySession This identifies the ring trading session.

N
Valid values:

Page 50
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

R1 = First morning ring

R2 = Second morning ring
R3 = First afternoon ring
R4 = Second afternoon ring
K1 = Morning kerb session
K2 = Afternoon kerb session
N = No session

10035 MDSource Data source system.

N
Valid values:
RK = Ring & Kerb
EL = Electronic Trading (from LMEselect
system)
MT = Matched Trades
CH = Clearing House
EX = Exchange (any other LME published
data which falls outside the other categories).

Standard Trailer
Y Component block, see section 13.2

10 Drop Copy

10.1 Business Message Types

FIX Message Type Dir. Comment Authorized

Name User Type

Trade Capture AD In The Trade Capture Report Request DC

Report Request message is used to make a request for
Trade Capture Reports to be sent to the
client that matches the criteria specified in
the request. Each Trade Capture Report
will contain one trade execution. Each
request could yield zero, one or more
Trade Capture Reports depending on the
criteria. A member can only receive Trade
Capture Reports for trade executions that
he is a party of. Trade Capture Reports

Page 51
  Cinnober Financial Technology AB

will be available for the last five trading

days.

Trade AQ
Out Sent as a reply to Trade Capture Report DC
Capture
Report Request if no trades matched the provided
Request Ack search criteria.

Trade AE
Out Sent as a reply to a Trade Capture Report DC
Capture
Report Request

10.2 Message Details

10.2.1 Trade Capture Report Request

Tag Field Name Req’d Comments

Standard Header Y MsgType = AD. Component block, see section

13.1

568 TradeRequestID Y Identifier for the trade request.

Valid values:
569 TradeRequestType Y
0 = All Trades
1 = Matches Trades
All Trades (0) and Matched Trades (1) will
generate the same result since all trades in
LMEselect 9 are matched.

Component block, see section 13.4

Parties N
Must be filled in to request trades for GUI users.

Instrument N Component block, see section 13.3

Today if not set.

580 NoDates N
Must be 1 or 2 specified. First is start date,
second is end date (or today if set).

TradeDate N To request trade from a specific date. Format is

75 YYYYMMDD.

TransactTime N Time criteria; get trade execution that happened

60 after this time. If absent YYYY<<DD-
00:00:00.000 is assumed, Format is
YYYYMMDD-HH:mm:ss.SSS in 24H.

Page 52
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

Standard Trailer Y Component block, see section 13.2

A user can only have one outstanding trade capture request in the system at the time.

10.2.2 Trade Capture Report Request Ack

Tag Field Name Req’d Comments

Standard Header Y MsgType = AQ. Component block, see section

13.1

568 TradeRequestID Y Identifier for the trade request.

Valid value is:

569 TradeRequestType Y
1 = Matched Trades

748 TotalNumTradeReports N Total number of trade reports returned.

Valid values:
749 TradeRequestResult Y
0 = Successful
1 = Invalid or unknown instrument
8 = TradeRequestType not supported
9 = Unauthorized for Trade Capture Report
Request
99 = Other

Valid values:
750 TradeRequestStatus Y
0 = Accepted
1 = Completed
2 = Rejected

Instrument N Component block, see section 13.3

Standard Trailer Y Component block, 13.2

10.2.3 Trade Capture Report

Tag Field Name Req’d Comments

Standard Header Y MsgType = AE. Component block, see section

13.1

Page 53
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

571 TradeReportID Y Identifier for the Trade Capture Report that is

unique within LMEselect.

568 TradeRequestID N ID taken from the request.

Valid values:
150 ExecType N
F = Trade
H = Trade Cancel

912 LastRptRequested N Indicates if this is the last report in the response

to a Trade Capture Report Request (AD). Only
used in response to Trade Capture Report
Request. The last message will have
LastRptRequested = Y and all previous
messages will be set to N.

570 PreviouslyReported Y The value here will always be N (false).

10022 SelectTradeID Y Example value TN-AA-20100331-00001.

Instrument Y Component block, see section 13.3

32 LastQty Y Trade quantity.

31 LastPx Y Trade price.

75 TradeDate Y Format is YYYYMMDD.

555 NoLegs N Set if ExecType = F (Trade) and the trade is

done in a multi-leg contract such as a carry, an
average contract, metal options or metal option
strips. (See section 6.1.4 Execution Reports for
Multi-Leg Contracts for details).

LegSymbol N A two-letter string describing the metal or index

600 for this leg. This is the start tag for the repeating
group and is mandatory if NoLegs > 0.

Describes the type of contract this leg

LegCFICode N
represents.
608

Page 54
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

Describes what kind of prompt type that this leg

LegPromptType N
uses.
10005
Valid values:
S = Single Prompt Date
R = Rolling Prompt Date
A = Average Prompt Date

Required if LegPromptType=“R”.
LegMaturityRollingPrompt N
Valid values:
10002
TOM = Tomorrow
C = Cash
3M = 3 Months

LegMaturityDate N Mandatory if LegPromptType=“S”. Used for daily,

611 weekly and monthly contracts. Represents the
prompt date for futures and the expiration date
for options and TAPO’s.

Represents whether the trade in this leg was a

LegSide N
buy or sell.
624
Valid values:
1 = Buy
2 = Sell

LegLastQty N Represents the trade quantity for this leg.

10003

LegLastPx N Represents the trade price for this leg.

637

60 TransactTime Y Format is YYYYMMDD-HH:mm:ss.SSS in 24H.

The clearing status.

10020 CCPMatchStatus Y
Valid values:
1 = UNDEFINED
2 = TO_BE_SENT_TO_CLEARING
3 = SENT_TO_CLEARING
5 = MATCHED_BY_CLEARING
6 = SUSPENDED_BY_CLEARING
8 = ERROR_FROM_CLEARING
15 = CROSS
16 = NOT APPLICABLE

10021 CCPMatchInfo N The clearing number.

Page 55
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

552 NoSides Y Number of sides in the report will always be 1.

Indicates Buy or Sell

Side Y
Valid values:
54
1 = Buy
2 = Sell

OrderID Y LMEselect order ID.

37

ClOrdID N Unique identifier sent by the entering firm. Will be

11 “NONE” for orders entered from the trading
client.

Parties N Component block, see section 13.4

Text N Free format text string. Info field from the Trading
58 Application.

Indicates if the order is entered either by an algo

529 OrderRestrictions N
trader or human.
Valid values:
D = Non-algorithmic (human)
E = Algorithmic (algo)

10048 InvestmentDecisionCountry N ISO Country Code of the branch responsible for

the person making the investment decision. This
field will be used only if LME performs
Transaction Reporting.

10049 ExecutionDecisionCountry N ISO Country Code of the branch responsible for

the person making the execution decision. This
field will be used only if LME performs
Transaction Reporting.

Indicates if the trader has a direct electronic

10050 DEA N
access.
Valid values:
Y = The trader has direct electronic access.
N = The trader does not have direct electronic
access.

Page 56
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

Indicates the type of trading capacity.

10051 TradingCapacity N
Valid values:
1 = DEAL (Dealing on own account)
2 = MTCH (Matched principal)
3 = AOTC (Any other capacity)

Indicates if matching order is an aggressor or

10057 AggressorIndicator N
not in the trade.
Y = Aggressor
N = Passive

Specifies the type of account associated with the

581 AccountType N
order.
Valid values:
1 = Client ISA
2 = House
3 = Client OSA
7 = Gross OSA

Standard Trailer Y Component block, see section 13.2

10.3 Workflows

Message TradeRequestID TradeReportID ExecType SelectTradeID LastRptRequested

-> (1) Trade 001 - - - -

Capture
Report Req

Page 57
  Cinnober Financial Technology AB

Message TradeRequestID TradeReportID ExecType SelectTradeID LastRptRequested

<- (2) 001 2001 Trade

TN-AA- N
Trade
Capture 20100408-0001
Report

<- (3) Trade 001 2002 Trade TN-AA- N

Capture 20100408-
Report 00004

<- (4) Trade 001 2003 Trade TN-AA- Y

Capture 20100408-
Report 00009

Note that Trade Capture Reports and Execution Reports could also be received by users logged on
to FIX Drop Copy server without requesting them. A logged on FIX Drop Copy user will receive
Execution Reports for own member (and member unit) trades and order updates. Also, it will receive
Trade Capture Reports for trades that the own member serves as a clearer for.

11 Market Data

11.1 Business Message Types

FIX Message Name Type Dir Comment Authorised User

Type

Market Data Request V In The Market Data Request is a MD + MDV

general request for market data on
specific securities.

Market Data Request Y Out The Market Data Request Reject is MD + MDV
Reject used when the exchange cannot
honour the Market Data Request
due to business or technical
reasons.

Market Data Message W Out The Market Data Message – MD + MDV

– Snapshot/Full Snapshot/Full Refresh will contain
Refresh Market Data Entries, each with the
complete data requested for one

Page 58
  Cinnober Financial Technology AB

FIX Message Name Type Dir Comment Authorised User

Type

contract.

Market Data Message X Out The Market Data Message – MD + MDV

– Incremental Refresh Incremental Refresh will contain
Market Data Entries. Each entry is
assigned an ID unique among all
other active entries and several
incremental updates of entries for
different instruments can be
included in one FIX Market Data
message.

FIX Market Data users are authorized to receive market data from LMEselect, i.e. MDSource = EL
(Electronic Trading).
FIX Market Data Vendors are authorized to receive market data from all sources, i.e. MDSource = EL
(Electronic Trading), RK (Ring & Kerb), MI (Member Indicative Quotes), MT (Matched Trades), CH
(Clearing House) and EX (any other LME published data which falls outside the other categories).

11.1.1 Market Data Request

A Market Data Request is a general request for market data on specific securities. A successful
Market Data Request returns one or more Market Data messages containing one or more Market
Data Entries. Each Market Data Entry is a Bid, an Ask, a Trade etc. Market Data Entries usually have
a price and a quantity associated with them.
Note that the Opening, Closing, Trading High/Low prices will only be published at the end of the
trading day in Select. The Trading High/Low is also published at the end of each trading session from
the Trading Ring.
You subscribe to market messages by a Market Data Request. A subscription request is either a
request for a snapshot, a snapshot + updates or a request to withdraw the subscription. A Market
Data Request can either be for Full Refresh or Incremental Refresh:

• Full Refresh - This mode is optimized to trade off increased bandwidth for simplicity in
processing and is intended for requests on only a few instruments. Each FIX Market Data
message in response to the request will contain the complete data requested for one
contract. If more than just the top of book is requested, this means that both sides, and all
price tiers, must be reported in that Market Data message. If for example, the CAD3M order
book is modified, the Market Data will contain the complete price depth up to 15 levels for
CAD3M.

• Incremental Refresh - This mode is optimized for handling requests for many instruments
while conserving bandwidth. For example, the system sends a new market data message
with updated information whenever an order is entered, modified or cancelled and the order

Page 59
  Cinnober Financial Technology AB

affects the accumulated quantity of any of the top 15 price levels. Several incremental
updates of entries for different instruments can be included in one FIX Market Data message.
Snapshot
A snapshot regarding bid, ask or both is quite simple to define. It’s the complete order book for a
security at a specific moment in time.
When Market Data Request is issued and trades are requested the snapshot will be defined as all
public trades for current date (unless Trade Replay is used, see section 11.1.5).
The snapshot will be represented by either MD Full Refresh or MD Incremental refresh, depending
on the value of MDUpdateType in the MD Request.

MDUpdateType (265) in MD Request Snapshot Response

0 = Full refresh MD Full refresh

1 = Incremental refresh
MD Incremental refresh

11.1.2 Market Data Message Price Depth

The price depth in Select can be derived from Market Data Messages. However, remember that
Market Data Message is a snapshot. For example, when the FIX client gets a Market Data Message
the order book for the contract should be scratched and rebuilt with the information in the Market
Data Message received.
The Market Data messages containing Order information (MDEntryType=0 or MDEntryType=1) will
contain the price depth for the bids and offers respectively.
It is notable that Select is sending a delete MDentry for the bottom row (i.e. last Bid or Offer price
from the price level depth specified) from the order book in case of a new order being entered in the
middle of order book. This happens in case of Incremental Refresh only.
When subscribing for Full Refresh Market Data messages on Bid and/or Offer you may get an update
Market Data message with NoMDEntries (tag 268) = 0 indicating that the order book was emptied.
An empty order book message does not contain MDSource (tag 10035), as MDSource is part of an
MDEntry. In order to receive empty order book message updates, do not specify the MDSource tag
when subscribing for FullRefresh. If MDSource = ‘EL’ is used, empty order book messages will not be
received.
A snapshot for an empty order book will not return an MDMessage. When orders are entered to the
order book, updates will be sent out.

11.1.3 Market Data Messages # of Messages

A Market Data Request is a request for Market Data information for one or more symbols. The
immediate reply is one message (containing order book) per contract for the requested symbol if
requesting Full Refresh. For Incremental Refresh, a message will be sent out only if the contract
contains any of the requested information (e.g. bid, offer, trade). The updates thereafter contain the
order book for modified contracts, NOT all order books for the subscribed symbol(s).

Page 60
  Cinnober Financial Technology AB

E.g. a request for Snapshot (bid and offer) in CA where there are three contracts (X, Y, Z) that have
prices will look as below:

Sequence:
1. A correct Market Data Request is sent.
2. A snapshot for contract X is sent to the client.
3. A snapshot for contract Y is sent to the client.
4. A snapshot for contract Z is sent to the client.
5. The sequence ends.

Page 61
  Cinnober Financial Technology AB

MDEntryType (269) MD User MDV Users

0 – Bid TOM, C, 3M TOM, C, 3M, 15M, 27M, 63M,

123M

1 – Ask
TOM, C, 3M TOM, C, 3M, 15M, 27M, 63M,
123M

2 – Trade TOM, C, 3M TOM, C, 3M, 15M, 27M, 63M,

123M

3 – Index Value No access No Rolling Prompt

4 – Opening Price C, 3M C, 3M, 15M, 27M, 63M, 123M

5 – Closing Price C, 3M C, 3M, 15M, 27M, 63M, 123M

6 – Settlement Price No access C

7 – Trading High C, 3M C, 3M, 15M, 27M, 63M, 123M

8 – Trading Low C, 3M C, 3M, 15M, 27M, 63M, 123M

E - Evening Evaluation No access C, 3M, 15M, 27M, 63M, 123M

F - Floor Closing Price C, 3M No access

M - Mean No access C, 3M, 15M, DEC1, DEC2, DEC3

P - Official Prices C, 3M C, 3M, 15M, DEC1, DEC2, DEC3

Q - Sterling Equivalent No access C, 3M

R - Exchange Rate No Rolling Prompt No Rolling Prompt

S - Asian Benchmark Price 3M 3M

V - Report Not Applicable Not Applicable

X – Report – Prompt Calendar Not Applicable Not Applicable

Delayed

Y – Report – Bullion Not Applicable Not Applicable

Z – Report Notification Not Applicable Not Applicable

Page 62
  Cinnober Financial Technology AB

11.1.4 End of Day Information

At the end of the trading day daily statistics are sent out from LMEselect. The system will publish
LMEselect Opening and Closing Prices, LMEselect Trading High, and LMEselect Trading Low for all
contracts that have traded during the day. All active subscriptions on MDEntryType 4=Opening Price,
5=Closing Price, 7=Trading High, and 8=Trading Low will receive the end of day information for the
particular symbol.

11.1.5 Rolling Prompts

The following rolling prompts exist for the Market Data messages.

11.1.6 Trade Replay

All trades disseminated by LME are assigned a trade sequence number, TradeSeqNo. This number
starts with 0 (zero) every day, and is increasing during the trading day. Furthermore, the trade
sequence numbers are assigned from a trade sequence number series, TradeSeqNoSeries. Trade
sequence numbers are unique and increasing within each trade sequence number series, which
means that the combination of TradeSeqNoSeries and TradeSeqNo uniquely identifies a trade within
a given trading day. There may, however, be gaps in the trade sequence numbers, i.e. all trade
sequence numbers are not necessarily used.
When setting up a subscription for trades, a client can choose to only receive trades with
TradeSeqNo higher than a certain value. This is useful (and the recommended behaviour) when re-
connecting after a FIX session has been down during the day, i.e. when some trades have already
been received.
In order to determine the suitable starting TradeSeqNo when setting up a subscription, the client
must examine TradeSeqNo and TradeSeqNoSeries from previously received trades the same trading
day. For each TradeSeqNoSeries, the client should store information about the highest TradeSeqNo
seen. A later subscription request should request later trades than the last seen trade. This is done
by specifying the last seen TradeSeqNo for each TradeSeqNoSeries.
Example
In this example, trades are numbered with the notation “TradeSeqNoSeries-TradeSeqNo”, i.e. 2-17
means TradeSeqNo 17 within TradeSeqNoSeries 2. In FIX market data messages, the
TradeSeqNoSeries and TradeSeqNo are two different fields (TradeSeqNoSeries = 7555 and
TradeSeqNo = 7554).
1. The client sets up the first subscription of the trading day. Since no trades are previously
received, TradeSeqNoSeries and TradeSeqNo can be omitted in the request, meaning that
the client requests a snapshot and subscription for all trades.
2. The client receives trades with the following trade sequence numbers:
3-20
3-21
1-40
1-41
3-22
1-43

Page 63
  Cinnober Financial Technology AB

3. The client keeps track of the highest seen TradeSeqNo for each TradeSeqNoSeries. The
highest numbers seen are:
- TradeSeqNoSeries 1: Highest TradeSeqNo is 43
- TradeSeqNoSeries 3: Highest TradeSeqNo is 22
There is also a gap; no trade was numbered 1-42.
4. The FIX connection is suddenly lost.
5. When the client has reconnected, it should set up a subscription with the following starting
points:
- TradeSeqNoSeries 1: Last seen TradeSeqNo 43
- TradeSeqNoSeries 3: Last seen TradeSeqNo 22
6. The client will receive new trades with the following numbers:
3-23
2-1
1-44
Since no TradeSeqNo was specified for TradeSeqNoSeries 2, all trades for
TradeSeqNoSeries 2 will be received.

11.1.7 Replay of Indicative Quotes

When requesting Indicative Quotes in a Market Data Request with any or both of MDEntryType bid
(0) and offer (1) specified, all today’s bids and offers are disseminated for all contracts that quotes
are entered for. There are no specific tags in the Market Data Request for replay of Indicative
Quotes, it is always performed.
The following details apply to both MD Snapshot/Full Refresh and MD Incremental Refresh.

• Generic

- For cancel, the Withdrawn (tag 10044) is set to ’Y’.

- MarketDepth (264) is disregarded.
- Indicative entries (MDSource = “MI”) are not mixed with entries with different MDSource.

• Snapshot
- All quotes, quote updates and cancels of the current day are sent out.
- All quotes, quote updates and cancels for the same contract are sent out in one single
message, ordered by time - the oldest first.

• Update
- All new quotes, quote updates and cancels are sent out.

11.1.8 Replay of prices from MOIC

When requesting MOIC prices in a Market Data Request with any or both of MDEntryType bid (0)
and offer (1) specified, all today’s bids and offers are disseminated for all contracts that prices are

Page 64
  Cinnober Financial Technology AB

entered for. There are no specific tags in the Market Data Request for replay of MOIC prices, it is
always performed.
The following details apply to both MD Snapshot/Full Refresh and MD Incremental Refresh.

• Generic
- All new, withdrawn and deleted session prices in MOIC are sent out in time order.
- Original price and timestamp are sent out at withdrawal and delete.

• For Snapshot; all events of the current day are sent out in original time order. This means
that for a withdrawn price both the original price and the withdrawn are sent out. All events –
entered, cancel or withdrawn for the same contract are sent out in one single message,
ordered by time – the oldest first. (Note: There is a separate FIX message sent for Bid and
Offer prices).

• For Update; the prices are sent out when they occur.
Withdrawal and deletion are distinguished as follows:

IncrementalRefresh FullRefresh

Deleted (new
Action MDUpdateAction Withdrawn Withdrawn
tag)

Withdrawn Delete Y - Y

Delete Delete - Y -

11.1.9 Replay of Reports

When requesting for reports using any of the MDEntryTypes v, x, y and z, all today’s versions of the
reports and notifications embraced by the MDRequest are disseminated. There are no specific tags
in the Market Data Request for replay of reports.

11.1.10 Rules for handling Market Data Messages

For market data messages, the following rules apply:

• It is possible to have several MDEntryTypes (tag 269) specified in the market data request.

• It is possible to have several Symbols (tag 55) specified in the market data request.

• All MDEntryType values specified must be available for all underlyings specified in Symbol.
Otherwise the user receives a Market Data Request Reject message.

• Market Data request requiring Symbol (tab 55) are:

- Bid (MDEntryType = 0)
- Offer (MDEntryType = 1)
- Trade (MDEntryType = 2)
- Opening Price (MDEntryType = 4)

- Closing price (MDEntryType = 5)

- Settlement price (MDEntryType = 6)

Page 65
  Cinnober Financial Technology AB

- Trading High (MDEntryType = 7)

- Trading Low (MDEntryType = 8)
- Floor Closing Price (MDEntryType = f)
- Mean (MDEntryType = m)
- Official Price (MDEntryType = p)
- Sterling Equivalent (MDEntryType = q)
- Asian Benchmark Price (MDEntryType = s)

• Market data requests that should not contain Symbol (tag 55) are:
- Official Index Value (MDEntryType = 3)
- Exchange Rate (MDEntryType = r)
- Report (MDEntryType = v)
- Bullion Report (MDEntryType = y)
- Prompt Calendar Report Delayed (MDEntryType = x)
- Report Notification (MDEntryType = z)
- Symbol is optional for Evening Evaluations for FX rates (MDEntryType = e), which is
further declared in this section.

• For Evening Evaluation rates (MDEntryType = e) the following applies with regards to
Symbol (tag 55):

- Provisional and Final Evening Evaluation FX Rates are always received in Market Data
Message regardless symbol being included or not in Market Data request.

- The following Evening Evaluation rates require Symbol (tag 55) to be included in the
Market Data request.
(1) Provisional Futures & Carries Evening Evaluation
(2) Final Futures & Carries Evening Evaluation
(3) Indicative Futures & Carries Evening Evaluation

• For the MDEntryTypes allowing or requiring Symbol (tag 55), it is possible to set
NoRelatedSym (tag 146) to zero and not specifying a symbol. This will result in no returning
messages because effectively the request indicates that no symbols are of interest.

• It is not possible to have several MDEntryTypes for MDEntryType = v, x, y and z. These must
be subscribed in separate market data requests.

11.2 Message Details

11.2.1 Market Data Request

Tag Field Name Req’d Comments

Standard Header Y MsgType= V. Component block, see section 13.1

Page 66
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

262 MDReqID Y Identifier that will be returned in Market Data

Messages. Must be unique, or the ID of previous
Market Data Request to unsubscribe if
SubscriptionRequestType (263) = Unsubscribe (2).

Valid values:
263 SubscriptionRequestType Y
0 = Snapshot
1 = Snapshot + Updates (Subscribe)
2 = Unsubscribe

Depth of market for Book Snapshot.

264 Market Depth Y
Valid values:
0 = Full book
1 = Top of book
2. N = Report best N price tiers of data
Note: There is a maximum limit for the number of
price tiers. When the limit is exceeded, the Market
Data Request will be rejected.

Valid values:
265 MDUpdateType N*
0 = Full refresh
1 = Incremental refresh

Specifies whether or not book entries should be

266 AggregatedBook N
aggregated. If omitted default value is Y.
Valid value is:
Y = One book entry per side per price.

267 NoMDEntryTypes Y The number of MDEntryType following.

Valid values:
MDEntryType Y
0 = Bid
269
1 = Offer
2 = Trade
3 = Index Value
4 = Opening Price
5 = Closing Price
6 = Settlement Price
7 = Trading High
8 = Trading Low
E = Evening Evaluation
F = Floor Closing Price
M = Mean
P = Official Price
Q = Sterling Equivalent
R = Exchange Rate

Page 67
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

S = Asian Benchmark Price

V = Report
X = Report – Prompt Calendar Delayed
Y = Report – Bullion
Z = Report Notification

7565 NoTradeSeqNoSeries N For trade replay.

TradeSeqNoSeries N For trade replay.

7555

TradeSeqNo N For trade replay.

7554

146 NoRelatedSym N The number of symbols following,

Symbol N The symbol. E.g. CA.

55

Data source system.

10035 MDSource N
Valid values:
RK = Ring & Kerb
MI = Member Indicative Quotes
EL = Electronic Trading (from LMEselect system)
MT = Matched Trades
CH = Clearing House
EX = Exchange (any other LME published data which
falls outside the other categories).

10041 NoMDReportCodes N Number of report codes.

MD Report Code N The 3 character short code for the report. Example:
10030 WSM, WHL, MOI, PRC, WHC, WHT.

Indicates if only the last trade should be returned. If

10042 LastTrade N
omitted default value is N.
Valid values:
Y = Return only the last trade.
N = Return all trades if TradeSeqNoSeries and
TradeSeqNo are not specified.

Standard Trailer Y Component block, see section 13.2

Page 68
  Cinnober Financial Technology AB

1) Required if SubscriptionRequestType (tag 263) = Snapshot + Subscribe (1) or if

SubscriptionRequestType (tag 263) = Snapshot (0)
SubscriptionRequestType (tag 263)
All values (0, 1, 2, 4, 5, 6, 7, 8, f, p, s and t) are implemented by the LME. However, for MDEntryType
= f (Floor Closing Price) only 0 = Snapshot is implemented. There is no possibility to request type 1
(snapshot + subscribe) combined with entry type = f (Floor Closing Prices). I.e. you cannot subscribe
for changes on Floor Closing Prices. If more than one MDEntryType is requested and f = Floor
Closing Price is one of them and Snapshot + Subscribe is requested, the whole request is rejected.
When requesting Floor Closing Prices you will get yesterday’s Floor Closing Prices.
If type 2 (unsubscribe) is requested you unsubscribe for the complete symbol. I.e. if you did
subscribe for bid, offer and trade in a market data request you cannot in a Market Data Request
unsubscribe for bid and offer and still keep the subscription for trade. It is possible, however, to
unsubscribe for a subset of symbols from the originating request and keep the subscription for the
rest of the symbols.
Snapshot + Subscribe on trades means that when you set up the subscription you’ll get all trades for
current date and after that each new trade (unless Trade Replay is used, see section 11.1.6).
MDEntryType (tag 269)

• Bid (0) – All bid orders from LMEselect and Trading Ring. Official and unofficial bid
prices from Trading Ring and Member Indicative Quotes.

• Offer (1) – All ask orders in LMEselect and Trading Ring. Official and unofficial ask
prices from Trading Ring and Member Indicative Quotes.

• Trade (2) – All trades in LMEselect, Trading Ring, Telephone Trades and Inter-Office
Trades. If not all previous trades are wanted in a snapshot, use the functionality of Trade
Replay.

• Index Value (3) – Official index values.

• Opening (4) – Opening is the LMEselect Opening price, i.e. the price of the first trade in
LMEselect in the contract during that trading day. This is part of the end of day
information sent out at the end of the trading day.

• Closing (5) – Closing is the LMEselect Closing price, i.e. the price of the last trade in
Select in the contract during that trading day. This is part of the end of day information
sent out at the end of the trading day.

• Settlement (6) – Settlement prices are established in LMEselect and Trading Ring only
for particular commodities. They are sent out once they have been confirmed.

• Trading High (7) – In LMEselect the Trading High is the highest trade price for the
contract during that trading day. This is part of the end of day information sent out at the
end of the trading day. In Trading Ring the Trading High is the highest bid price for the
contract during a trading period. It is sent out at the end of each trading period.

• Trading Low (8) – In LMEselect the Trading Low is the lowest trade price for the
contract for that trading day. This is part of the end of day information sent out at the end
of the trading day. In Trading Ring the Trading Low is the lowest ask price for the
contract during a trading period. It is sent out at the end of each trading period.

• Evening Evaluation (e) – Evening evaluations for FX rates, futures and TAPOs from
clearing.

Page 69
  Cinnober Financial Technology AB

• Floor Closing Price (f) – Floor Closing Price refers to yesterday’s floor closing prices
from LMEselect. It is not possible to subscribe to Floor Closing Prices, only snapshot is
supported.

• Mean (m) – From Trading Ring Mean is the monthly average official mean. From
Clearing Mean is monthly moving average price and the monthly average settlement
price for TAPOs.

• Official Price (p) – Official Prices are available from LMEselect only for particular
commodities.

• Sterling Equivalent (q) – Sterling Equivalent prices are available from Trading Ring for
cash and 3M contracts for particular commodities.

• Exchange Rate (r) – Exchange Rate is available from Trading Ring for daily, monthly
and daily moving monthly average FX rates.

• Asian Benchmark Price (s) – Asian Benchmark is used as reference price and is only
available for 3M contracts for particular commodities.

• Report (v) – All other reports available from the Exchange that are not of type bullion or
prompt calendar delayed.

• Report – Prompt Calendar Delayed (x) – A report containing the prompt calendar
delayed data from the Exchange.

• Report – Bullion (y) – A report containing bullion data from the Exchange.

• Report Notification (z) – Notifications that reports are available from the Exchange.

FIX Market Data users and Market Data Vendors are allowed to subscribe for the following market
data:

MDEntryType (269) Authorized User Type

0 – Bid MD + MDV

1 – Ask MD + MDV

2 – Trade MD + MDV

3 – Index Value MDV

4 – Opening Price MD + MDV

5 – Closing Price MD + MDV

6 – Settlement Price MDV

7 – Trading High MD + MDV

8 – Trading Low MD + MDV

Page 70
  Cinnober Financial Technology AB

MDEntryType (269) Authorized User Type

E – Evening Evaluation MDV

F – Floor Closing Price MD

M – Mean MDV

P – Official Prices MD + MDV

Q – Sterling Equivalent MDV

R – Exchange Rate MDV

S – Asian Benchmark Price MD + MDV

V – Report MDV

X – Report – Prompt Calendar Delayed MDV

Y – Report – Bullion MDV

Z – Report Notification MDV

11.2.2 Market Data Request Reject

Tag Field Name Req’d Comments

Standard Header Y MsgType = Y. Component block, see section

13.1

262 MDReqID Y Unique identifier will be returned in Market Data

Messages.

Valid values:
281 MDReqRejReason N
0 = Unknown symbol
1 = Duplicate request ID
4 = Unsupported subscription request type
5 = Unsupported market depth
6 = Unsupported market update type
7 = Unsupported aggregated book
8 = Unsupported entry type
A = Unsupported scope
B = Unsupported open, close or settle flag
C = Unsupported implicit delete

Page 71
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

W = This MDEntryType does not support the

requesting underlying
X = Internal server error
Y = Unknown request ID
Z = Other
Please note that value W-Z deviates from the
FIX 4.4 Standard.

58 Text N Free format text.

Standard Trailer Y Component block, see section 13.2

11.2.3 Market Data – Snapshot/Full Refresh

Tag Field Name Req’d Comments

Standard Header Y MsgType = W. Component block, see section

13.1

262 MDReqID N Unique identifier taken from the request.

10028 PublishTime N Publish time.

Instrument N Component block, see section 13.3

268 NoMDEntries Y The number of entries within the message.

Valid values:
MDEntryType Y
0 = Bid
269
1 = Offer
2 = Trade
3 = Index Value
4 = Opening Price
5 = Closing Price
6 = Settlement Price
7 = Trading High
8 = Trading Low
E = Evening Evaluation
F = Floor Closing Price
M = Mean
P = Official Price
Q = Sterling Equivalent
R = Exchange Rate
S = Asian Benchmark Price

Page 72
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

V = Report
X = Report – Prompt Calendar Delayed
Y = Report – Bullion
Z = Report Notification

MDEntryPx N For orders in carry contracts, a contango is

270 expressed as a ‘negative price’ and a
backwardation is expressed as a ‘positive price’.

Valid values:
MDEntryPxType N
0 = Real-Time
10013
1 = Provisional
2 = Confirmed
3 = Official
4 = Unofficial
5 = Daily
6 = Monthly Average
7 = Monthly Moving Average
8 = Indicative
9 = Reconfirmed

Currency N Identifies currency used for price. Absence of

15 this field is interpreted as the default for the
security.

MDEntryPxDifferential N Differential from 3M price.

10029

MDEntryPremium N Premium value.

10036

MDEntryMarketMakerID N Market maker ID.

10039

Withdrawn N Indicates if the price has been withdrawn.

10044

Deleted N Indicates if the price is deleted.

10046

MDEntrySize N Volume for the entry. Busted trades are

271 representative with a negative volume.

MDEntryDate N UTC date in format YYYYMMDD.

272

Page 73
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

MDEntryTime N Time formatted as HH:mm:ss.SSS.

273

Space-delimited list of conditions describing a

Trade Condition N
trade.
277
Valid values:
U = Exchange Last (when update last paid)
0 = Cancel (Busted trade)

TradeSeqNoSeries N For trade replay.

7555

TradeSeqNo N For trade replay.

7554

TradeDate N For trade replay. Format is YYYYMMDD.

75

TradeTime N Time of trade.

10040

This identifies trade ring session.

MDEntrySession N
Valid values:
10037
R1 = First morning ring
R2 = Second morning ring
R3 = First afternoon ring
R4 = Second afternoon ring
K1 = Morning kerb session
K2 = Afternoon kerb session
N = No session

Data source system.

MDSource N
Valid values:
10035
RK = Ring & Kerb
MI = Member Indicative Quotes
EL = Electronic Trading (from LMEselect
system)
MT = Matched Trades
CH = Clearing House
EX = Exchange (any other LME published data
which falls outside the other categories).

10030 MDReportCode N The 3 character short code for the report.

Example: WSM, WHL, MOI, PRC, WHC, WHT.

Page 74
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

10031 MDReportName N The primary identifier for the report.

10032 MDReportVersion N The report version. This allows for re-publishing

of the same report (for example, to correct
errors).

10033 MDReportFragmentNo N For large report that are fragmented into multiple
messages, this is the fragment number (1..n).

10034 MDReportLastFragment N This indicates that this is the last fragment of the
report.

212 XmlDataLen N Length of the XmlData (tag 213) data block.

213 XmlData N Actual XML data stream in compressed format.

Note: may contain embedded SOH characters.

This identifies the trade type. Valid values:

10038 MDEntryTradeType N
IO = Inter-office
R1 = First morning ring
R2 = Second morning ring
R3 = First afternoon ring
R4 = Second afternoon ring
K1 = Morning kerb session
K2 = Afternoon kerb session
C1 = Basis first morning ring
C2 = Basis second morning ring
C3 = Basis first afternoon ring
C4 = Basis second afternoon ring
D1 = Basis morning kerb
D2 = Basis afternoon kerb

10043 MaturityExchangeRateDate N Prompt date for Exchange Rate. UTC date in

format YYYYMMDD.

Standard Trailer Y Component block, see section 13.2

Busted trades will also be sent out as Market Data Message. A busted trade will be represented with
tag 277 (TradeCondition) that will have value 0 (Cancel).

Page 75
  Cinnober Financial Technology AB

11.2.4 Market Data – Incremental Refresh

Tag Field Name Req’d Comments

Standard Header Y MsgType = X. Component block, see section

13.1

262 MDReqID N Unique identifier will be returned in Market Data

Messages.

268 NoMDEntries Y The number of entries within the message.

Type of Market Data update action.

MDUpdateAction Y
Valid values:
279
0 = New
1 = Change
2 = Delete

Valid values:
MDEntryType N
0 = Bid
269
1 = Offer
2 = Trade
3 = Index Value
4 = Opening Price
5 = Closing Price
6 = Settlement Price
7 = Trading High
8 = Trading Low
E = Evening Evaluation
F = Floor Closing Price
M = Mean
P = Official Price
Q = Sterling Equivalent
R = Exchange Rate
S = Asian Benchmark Price
V = Report
X = Report – Prompt Calendar Delayed
Y = Report – Bullion
Z = Report Notification

Instrument N Component block, see section 13.3

MDEntryPx N For orders in carry contracts, a contango is

270 expressed as a ‘negative price’ and a
backwardation is expressed as a ‘positive price’.

Valid values:
MDEntryPxType N
0 = Real-Time
10013

Page 76
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

1 = Provisional
2 = Confirmed
3 = Official
4 = Unofficial
5 = Daily
6 = Monthly Average
7 = Monthly Moving Average
8 = Indicative
9 = Reconfirmed

Currency N Identifies currency used for price. Absence of

15 this field is interpreted as the default for the
security.

MDEntryPxDifferential N Differential from 3M price.

10029

MDEntryPremium N Premium value.

10036

MDEntryMarketMakerID N Market maker ID.

10039

Withdrawn N Indicates if the price has been withdrawn.

10044

MDEntrySize N Volume for the entry. Busted trades are

271 represented with a negative volume.

MDEntryDate N UTC date in format YYYYMMDD.

272

MDEntryTime N Time UTC formatted as 16:04:51.984

273

Space-delimited list of conditions describing a

TradeCondition N
trade.
277
Valid values:
U = Exchange Last (when update last paid)
0 = Cancel (Busted trade)

TradeSeqNoSeries N For trade replay.

7555

TradeSeqNo N For trade replay.

Page 77
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

7554

TradeDate N For trade replay. Format is YYYYMMDD.

75

TradeTime N Time of trade.

10040

Valid value is:

MatchType N
574 4 = Auto-match

Valid values:
MDEntrySession N
R1 = First morning ring
10037
R2 = Second morning ring
R3 = First afternoon ring
R4 = Second afternoon ring
K1 – Morning kerb session
K2 = Afternoon kerb session
N = No session

Data source system.

MDSource N
Valid values:
10035
RK = Ring & Kerb
MI = Member Indicative Quotes
EL = Electronic Trading (from Select system)
MT = Matched Trades
CH = Clearing House
EX = Exchange (any other LME published data
which falls outside the other categories).

10030 MDReportCode N The 3 character short code for the report.

Example: WSM, WHL, MOI, PRC, WHC, WHT.

10031 MDReportName N The primary identifier for the report.

10032 MDReportVersion N The report version. This allows for re-publishing

of the same report (for example, to correct
errors).

10033 MDReportFragmentNo N For large reports that are fragmented into

multiple messages, this is the fragment number
(1..n).

Page 78
  Cinnober Financial Technology AB

Tag Field Name Req’d Comments

10034 MDReportLastFragment N This indicates that this is the last fragment of the
report.

212 XmlDataLen N Length of the XmlData (tag 213) data block.

213 XmlData N Actual XML data stream in compressed format.

Note: may contain embedded SOH characters.

This identifies the trade type.

10038 MDEntryTradeType N
Valid values:
IO = Inter-office
R1 = First morning ring
R2 = Second morning ring
R3 = First afternoon ring
R4 = Second afternoon ring
K1 = Morning kerb session
K2 = Afternoon kerb session
C1 = Basis first morning ring
C2 = Basis second morning ring
C3 = Basis first afternoon ring
C4 = Basis second afternoon ring
D1 = Basis morning kerb
D2 = Basis afternoon kerb

10043 MaturityExchangeRateDate N Prompt date for Exchange Rate. UTC date in

format YYYYMMDD.

Standard Trailer Y Component block, see section 13.2

Busted trades will also be sent out as Market Data Messages. A busted trade will be represented
with tag 277 (TradeCondition) that will have value 0 (Cancel).

11.3 Workflows

11.3.1 Market Data Message Sequence

Scenario 1:
Table name: Market Data Request (Message type = “V”)

Tag Value Meaning

262 001

Page 79
  Cinnober Financial Technology AB

Tag Value Meaning

263
0 Snapshot

264 0 Full book

265 0 Full refresh

267 1 One entry type requested

1 Offer requested
269

146 1 One symbol requested

CA Symbol CA
55

Sequence:

1. A correct Market Data Request is sent.

2. A snapshot is sent to the client.
3. The sequence ends.

Scenario 2:
Table name: Market Data Request (Message type = “V”)

Tag Value Meaning

262 001

263
1 Snapshot + Subscribe

Page 80
  Cinnober Financial Technology AB

Tag Value Meaning

264 0 Full book

265 0 Full refresh

267 1 One entry type requested

1 Offer requested
269

146 1 One symbol requested

CA Symbol CA
55

Sequence:

1. A correct Market Data Request is sent.

2. X # of Market Messages is sent to the client.
3. A correct Market Data Request (Unsubscribe) is sent.
4. The sequence ends.
In this scenario the requestor will get a Market Data Message each time the order book for CA is
modified.
Scenario 3:

Requesting Snapshot + Subscribe for Offer and Floor Closing Prices. A request for Snapshot +
Subscribe with Floor Closing Prices is illegal.
Table name: Market Data Request (Message type = “V”)

Tag Value Meaning

262 001

Page 81
  Cinnober Financial Technology AB

Tag Value Meaning

263
1 Snapshot + Subscribe

264 0 Full book

265 0 Full refresh

267 2 Two entry types requested

F Floor Closing Prices (Only Snapshot)

269

1 Offer
269

146 1 One symbol requested

CA Symbol CA
55

Sequence:

1. An incorrect Market Data Request is sent.

2. Request is rejected
3. The sequence ends.
In this scenario the requestor will get a Market Data Request Reject message since the
SubscriptionRequestType (snapshot + subscribe) is not supported for Floor Closing Prices
(MDEntryType = f).

Scenario 4:
Requesting Snapshot + Subscribe for TWAP Official Prices.
Table name: Market Data Request (Message type = “V”)

Page 82
  Cinnober Financial Technology AB

Tag Value Meaning

262 001

263
1 Snapshot + Subscribe

264 0 Full book

265 0 Full refresh

267 1 One entry type requested

P Official Prices
269

146 1 One symbol requested

PN Symbol PN (Only Plastic Underlyings)

55

Sequence:

1. A correct Market Data Request is sent.

2. X # of Market Messages is sent to the client.
3. A correct Market Data Request (Unsubscribe) is sent.
4. The sequence ends.
In this scenario the requestor will get a set of Market Data Messages each time the Trade Weighted
Average Price (TWAP) of specific contracts in the plastic underlying changes, or if the price
calculation changes state. The prices can be of type (MDEntryPxType) “Real-Time”, “Provisional” or
“Confirmed”. TWAP is calculated on the cash contract and the first and second monthly contract on
any given plastic underlying.

Page 83
  Cinnober Financial Technology AB

12 General Messages

12.1 Business Message Types

FIX Message Name Type Dir. Comment

Business Message Reject J Out See section 4.2

12.2 Message Details

12.2.1 Business Message Reject

Tag Field Name Req’d Comments

Standard Header Y MsgType = j. Component block, see section

13.1

45 RefSeqNum N Reference message sequence number.

372 RefMsgType Y The message type of the FIX message being

referenced.

379 BusinessRejectRefID N The value of the business-level “ID” field on

the message being referenced.

Code to identify reason for a Business

380 BusinessRejectReason Y
Message Reject (j) message.
Valid values:
0 = Other
3 = Unsupported Message Type

58 Text N An error message giving the reason for

rejecting the request.

Standard Trailer Y Component block, see section 13.2

Page 84
  Cinnober Financial Technology AB

13 Common Component Block

All Session and Application Messages use the Standard Message Header and Trailer, as specified in
the FIX 4.4 Specification. The following sections describe the FIX fields that are supported by the FIX
server.

13.1 Standard Header

Tag Name Req’d Comments

8 BeginString Y FIX 4.4 (must be first field in message).

9 BodyLength Y Message length, in bytes (must be second field in

message). The field consists of 7 characters.

Example: A message with body length 144

sets tag 9=0000144.

35 MsgType Y Defines message type (must be third field in

message).

49 SenderCompID Y Assigned value used to identify firm sending

message.

56 TargetCompID Y Assigned value used to identify receiving firm.

34 MsgSeqNum Y Integer message sequence number.

Indicates possible retransmission of message with

43 PossDupFlag N
this sequence number.
Always required for retransmitted messages, whether
prompted by the sending system or as a result of a
resend request.

52 SendingTime Y Time of message transmission. In UTC. Format is

YYYYMMDD-HH:mm:ss.SSS in 24H.

Indicates that message may contain information that

97 PossResend N
has been sent under another sequence number.
Valid values:
Y = Possible resend
N = Original transmission

Page 85
  Cinnober Financial Technology AB

Tag Name Req’d Comments

122 OrigSendingTime N Required for message re-sent as a result of a

ResendRequest. If data is not available set to same
value as SendingTime. Format is YYYYMMDD-
HH:ss.SSS in 24H.

369 LastMsgSeqNumProcessed N The last MsgSeqNum (tage 34) value received by the
FIX server.

13.2 Standard Trailer

Tag Name Req’d Comments

10 CheckSum Y A three byte simple checksum. See FIX 4.4 Specification for a
detailed description. Always the last field in the message.

13.3 Instrument Component Block

Tag Name Req’d Comments

55 Symbol Y The symbol: eg. CA

Indicates the type of security using ISO 10962 standard,

461 CFICode N
Classification of Financial Instruments (CFI Code) values.
See section 6.1.2 for a complete list of the allowed values.
Required for NewOrderSingle,
OrderCancelRequestReplaceRequest,
OrderCancelRequest and TradeCaptureReportRequest.

The number of instrument legs following.

10010 NoOfInstrumentLegs N
Valid values:
2 – for carry contracts
1 – for all other contracts

Defines what prompt type that is to be used.

PromptType Y
Valid values:
10004
S = Single Prompt Date
R = Rolling Prompt Date
A = Average Prompt Date

Required if PromptType=‘R’.
MaturityRollingPrompt N

Page 86
  Cinnober Financial Technology AB

Tag Name Req’d Comments

Valid values:
10000
TOM = Tomorrow
C = Cash
3M = 3 Months
15M = 15 Months
27M = 27 Months
63M = 63 Months
123M = 123 Months
D = Day
W = Week
M = Month
Q = Average
N1 = Near 1
N2 = Near 2
N3 = Near 3
F1 = Far 1
F2 = Far 2
F3 = Far 3
DEC1 = December 1
DEC2 = December 2
DEC3 = December 3

Required if PromptType = ‘S’. Used for daily, weekly and

MaturityDate N
monthly contracts.
541
Will be populated with the absolute date for rolling
prompts on outgoing messages (ie. if PromptType = ‘R’).
Represents:
- Prompt date for futures
- Expiration date for options and TAPO’s (YYYYMMDD)

Required if PromptType = ‘A’. Used for average contracts.

MaturityAveragePrompt N
10001 Valid values are, as an example, “3Q11” for quarterly
contracts, “2H12” for half-year contracts and “1Y11” for
year contracts.

202 StrikePrice N Required if CFICode defines an option or TAPO.

If NoOfInstrumentLegs = 2, the instrument block describes a carry contract. The first entry in the
repeating group then describes the buy leg, and the second entry describes the sell leg. (This means
that a buy order in the contract buys the first leg and sells the second. A sell order performs the
opposite.) The maturity date for the buy leg must always be earlier in time than the maturity date for
the sell leg.
The Strike price (tag 202) field is only applicable if the CFICode (tag 461) describes an option or
TAPO, otherwise the message is considered invalid.

Page 87
  Cinnober Financial Technology AB

The contract currency is always USD.

Note that a syntactically correct instrument block might be rejected due to business rules in the
Select system. For example, a carry buy leg must not consist of an average prompt. See section 15
for Instrument Block examples.

13.4 Parties Block

Tag Name Req’d Comments

453 NoPartyID’s N Number of parties specified.

PartyID Y ID of firm or trader. Required if NoPartyID’s (453) > 0.

448

Identifies the type of PartyID (Eg. Executing Broker).

PartyRole Y
Required if NoPartyID’s (453) > 0.
452
Valid values:
1 = Executing Firm
3 = Client ID
4 = Clearing Firm
7 = Entering Firm
11 = Order Origination Trader
24 = Customer Account
35 = Liquidity Provider
36 = Entering Trader
66 = Market Maker
300 = Investment Decision Within Firm
301 = Execution Decision Within Firm
304 = Algo or Human Detail

The following Party Roles are required in the New Single

Order and Order Cancel/Replace requests:
3 = Client ID
11 = Order Origination Trader
304 = Algo or Human Detail

301 = Execution Decision Within Firm

The following Party roles are not validated by the system, but are the user’s responsibility to set
correctly on the New Single Order and Order Cancel/Replace requests:

• 3 = Client ID (For all Client orders the Client ID should be a LEI or Client identifier. If that is not
available, the field should be populated with the value AGGR or PNAL.)

• 35 = Liquidity Provider (This should be set if the trader qualifies for Liquidity Provider initiative.)

• 66 = Market Maker (This should be set if the trader qualifies for a Market Maker initiative.)

Page 88
  Cinnober Financial Technology AB

14 LME Specific Tags

Tag Field Name Type Comment

7554 TradeSeqNo Int Used for trade replay.

7555 TradeSeqNoSeries Int Used for trade replay.

7565 NoTradeSeqNoSeries Int Used for trade replay.

Valid values:
10000 MaturityRollingPrompt String
C = Cash
3M = 3 Months
15M = 15 Months
27M = 27 Months
63M = 63 Months
123M = 123 Months
D = Day
W = Week
M = Month
N1 = Near 1
N2 = Near 2
N3 = Near 3
F1 = Far 1
F2 = Far 2
F3 = Far 3

10001 MaturityAveragePrompt String Used to express, eg. “3Q11”.

10002 LegMaturityRollingPrompt String Used to express “TOM”, “C” or “3M”

10003 LegLastQty Qty Used to express trading volume in a leg of a

multi-leg contract.

Used to define what kind of prompt type that

10004 PromptType Char
is used in the legs in an execution report.
Valid values:
S = Single date prompt
R = Rolling prompt
A = Average prompt

Used to define what prompt is used in the

10005 LegPromptType Char
legs of an execution report.
Valid values:
S = Single Date Prompt

Page 89
  Cinnober Financial Technology AB

Tag Field Name Type Comment

R = Rolling Prompt

Used to define strike type.

10006 SecurityStrikeType Char
Values:
S=Single
T=Table

10007 NoStrikeTableRows Int Number of strike table rows if strike type

equals ‘T’.

10008 StrikeLowLimit Float Low limit for strike price.

10009 StrikeGradation Float Gradation for strike price.

10010 NoOfInstrumentLegs Int Used in the instrument block to define

whether the contract is a carry contract or not.

10011 RollingPromptDate Int Prompt date.

Type of Price distributed. Used in

10013 MDEntryPxType Int
MarketDataSnapshotFullRefresh and
MarketDataIncrementalRefresh.
Valid values:
0 = Real-Time
1 = Provisional
2 = Confirmed
3 = Official
4 = Unofficial
5 = Daily
6 = Monthly Average
7 = Monthly Moving Average
8 = Indicative
9 = Reconfirmed

Used in Trade Capture Report. LME Clear

10020 CCPMatchStatus String
clearing status.
Valid values:
1 = UNDEFINED
2 = TO_BE_SENT_TO_CLEARING
3 = SENT_TO_CLEARING
5 = MATCHED_BY_CLEARING
6 = SUSPENDED_BY_CLEARING
8 = ERROR_FROM_CLEARING
15 = CROSS
16 = NOT APPLICABLE

Page 90
  Cinnober Financial Technology AB

Tag Field Name Type Comment

10021 CCPMatchNo String Used in Trade Capture Report. LME Clear

clearing number.

10022 SelectTradeID String Used in Trade Capture Report. Example

value – TN-AA-20060331-000001.

10026 IsMonthlyCOntract String Used in Security List. ‘Y’ if it is a monthly

contract or else the tag is omitted.

10027 NoOfMonthlyCOntracts String Used in Security List. The total number of

monthly contracts for a specific symbol.

10028 PublishTime String Price publish time.

10029 MDEntryPxDifferential Float Differential from 3M price.

10030 MDReportCode String The 3 character short code for the report.
Example: WSM, WHL, MOI, PRC, WHC,
WHT.

10031 MDReportName String The primary identifier for the report.

10032 MDReportVersion Int The report version. This allows for

republishing of the same report (for example,
to correct errors).

10033 MDReportVersion Int For large reports that are fragmented into
multiple messages, this is the fragment
number (1..n).

This indicates that this is the last fragment of

10034 MDReportLastFragment Boolean
the report.
Valid values:
Y = This is the last report fragment.
N = This is not the last report fragment.

Data source system.

10035 MDSource String
Valid values:
RK = Ring & Kerb
MI = Member Indicative Quotes
EL = Electronic Trading (from Select system)
MT = Matched Trades
CH = Clearing House

Page 91
  Cinnober Financial Technology AB

Tag Field Name Type Comment

EX = Exchange (any other LME published

data which falls outside the other categories).

10036 MDEntryPremium Float Premium value.

This identifies trade ring session.

10037 MDEntrySession String
Valid values:
R1 = First morning ring
R2 = Second morning ring
R3 = First afternoon ring
R4 = Second afternoon ring
K1 = Morning kerb session
K2 = Afternoon kerb session
N = No session

This identifies the trade type.

10038 MDEntryTradeType String
Valid values:
IO = Inter-office
R1 = First morning ring
R2 = Second morning ring
R3 = First afternoon ring
R4 = Second afternoon ring
K1 = Morning kerb session
K2 = Afternoon kerb session
C1 = Basis first morning ring
C2 = Basis second morning ring
C4 = Basis second afternoon ring
D1 = Basis morning kerb
D2 = Basis afternoon kerb

10039 MDEntryMarketMakerID String Market maker ID.

10040 TradeTime String Time of trade.

10041 NoMDReportCodes Int Number of report codes.

Indicates if only the last trade should be

10042 Last Trade Boolean
returned from a MarketDataRequest
message. If omitted default value is N.
Valid values:
Y = Return only the last trade.
N = Return all trades if TradeSeqNoSeries
and TradeSeqNo are not specified.

10043 MaturityExchangeRateDate String Prompt date for Exchange Rate. UTC date in

Page 92
  Cinnober Financial Technology AB

Tag Field Name Type Comment

format YYYYMMDD.

Indicates if the floor price has been

10044 Withdrawn Boolean
withdrawn.
Valid values:
Y = The floor price has been withdrawn.
N = The floor price has not been withdrawn.

Indicates if the floor price is deleted or the

10046 Deleted Boolean
Indicative Quote is cancelled.
Valid value:
Y = The floor price has been deleted or the
Indicative Quote is cancelled.

10048 InvestmentDecisionCountry String ISO Country Code of the branch responsible

for the person making the investment
decision. This field will be used only if LME
performs Transaction Reporting.

10049 ExecutionDecisionCountry String ISO Country Code of the branch responsible

for the person making the execution decision.
This field will be used only if LME performs
Transaction Reporting.

Indicates if the trader has a direct electronic

10050 DEA Boolean
access.
Valid values:
Y = The trader has direct electronic access.
N = The trader does not have direct electronic
access.

Indicates the type of trading capacity.

10051 TradingCapacity String
Valid values:
1 = DEAL (Dealing on own account)
2 = MTCH (Matched principal)
3 = AOTC (Any other capacity)

Page 93
  Cinnober Financial Technology AB

15 Instrument Block Examples

AADC
Cash contract for Aluminium Alloy:

Tag Name Value

55 Symbol AA

461
CFICode FCEPS

10010 NoOfInstrumentLegs 1

10004 PromptType R

10000 MaturityRollingPrompt C

541 MaturityDate 20100927

CADDEC10
December 2010 contract for Copper. Note that the monthly contract DEC10 means the third
Wednesday in December 2010, i.e. 2010-12-15:

Tag Name Value

55 Symbol CA

461 CFICode FCEPS

10010 NoOfInstrumentLegs 1

10004 PromptType S

541 MaturityDate 20101215

MXDJUN11
June 2011 future on the LME Index:

Tag Name Value

55 Symbol MX

461 CFICode FFICS

Page 94
  Cinnober Financial Technology AB

Tag Name Value

10010 NoOfInstrumentLegs 1

10004 PromptType S

541 MaturityDate 20110608

NID1Q11
First quarter 2011 average contract for Nickel:

Tag Name Value

55 Symbol NI

461 CFICode FCEPS

10010 NoOfInstrumentLegs 1

10004 PromptType A

10001 MaturityAveragePrompt 1Q11

AAD1H11

First half year 2011 average contract for Aluminium Alloy:

Tag Name Value

55 Symbol AA

461 CFICode FCEPS

10010 NoOfInstrumentLegs 1

10004 PromptType A

10001 MaturityAveragePrompt 1Q11

Page 95
  Cinnober Financial Technology AB

AADTOMNEXT
Carry contract between TOM and C in Aluminium Alloy:

Tag Name Value

55 Symbol AA

461 CFICode FCEPS

10010 NoOfInstrumentLegs 2

10004 PromptType R

10000 MaturityAveragePrompt TOM

541 MaturityDate 20110121

10004 PromptType R

10000 MaturityRollingPrompt C

541 MaturityDate 20110124

AADDEC10-DEC11
Carry contract between DEC10 and DEC11 in Aluminium Alloy:

Tag Name Value

55 Symbol AA

461 CFICode FCEPS

10010 NoOfInstrumentLegs 2

10004 PromptType S

541 MaturityDate 20101215

10004 PromptType S

541 MaturityDate 20111221

Page 96
  Cinnober Financial Technology AB

AADJUN11_1400C
Call option on the June 2011 AA future with strike 1400 in Aluminium Alloy:

Tag Name Value

55 Symbol AA

461 CFICode OCAFPS

10010 NoOfInstrumentLegs 1

10004 PromptType S

541 MaturityDate 20110601

202 StrikePrice 1400

AADOCT11_1500TP

TAPO put for October 2011 at strike 1500 in Aluminium Alloy:

Tag Name Value

55 Symbol AA

461 CFICode OPXTCS

10010 NoOfInstrumentLegs 1

10004 PromptType S

541 MaturityDate 20111031

202 StrikePrice 1500

Page 97