Pillar Gateway – Functional Differences

Pillar Gateway – Functional Differences
Pillar Gateway – Functional Differences
Binary Protocol – Session Configuration
UGW
 Certain session configuration settings may be specified by the firm via the “Logon
Gateway
Request” message. These can be changed intraday by logging off and logging back in
with the new specified settings.
Pillar
 The “Session Configuration Acknowledgment" message notifies the firm at start of day
Gateway
of their current session configuration settings. The settings can be changed intraday
without logging off by sending the “Session Configuration Request” message. For
details, refer to the “Pillar Gateway Binary Protocol Specification.”
Binary Protocol – Session Layer
UGW
 The default Heartbeat Interval for a session is 60 seconds, and may be changed by
Gateway
manual configuration. During periods of activity, any message may be sent by the firm
in lieu of a Heartbeat message.
 A user defined ClOrdID is specified by the firm on every incoming Application Layer
message.
 A client sending time is not provided by the firm on any incoming messages.
Pillar
 The heartbeat interval is set at 1 second, and is not configurable. A heartbeat message
Gateway
must be sent regardless of other message activity.
 In addition to a user defined ClOrdID, a numeric “SeqMsgID” is applied by the firm on
every incoming Application Layer message. The value provided must increment by one
with each message sent, and will be validated by Pillar.
 A timestamp is required on all incoming Application Layer messages, represented in
nanoseconds since UNIX Epoch. Pillar will convert the value provided by the firm to local
time, and validate that it matches the current business day. If not, the message will be
rejected.
 New – Reference data messages will be provided at start of day on the GT (Gateway-toTrader) and REF (Reference Data) streams for each session.
o The reference data messages cover Symbols, MPV Classes and Levels, Session
Configurations and MPID Status.
o In the event of intraday changes, the applicable messages will be published to
the GT and REF streams intraday.
FIX Protocol – Message Sequence Numbers
UGW
 The firm may reset both the client and Exchange side sequence numbers to 0 upon login
Gateway
by sending ResetSeqNumFlag (141) = Y on the “Logon Request” message.
Pillar
Gateway

The firm may not reset the client nor Exchange side sequence numbers on the “Logon
Request” message.
o New – The next expected client side sequence number is provided by the
Exchange in the tag “NextExpectedMsgSeqNum” (789) on both the “Logon
Accept” and “Logout” messages.
o The firm may increase the client side sequence number by sending the
“Sequence Reset” message, but may never reset it.
o For more information, see the “Pillar FIX Session Layer Handling” section of the
“NYSE Pillar Gateway FIX Protocol Specification.”
FIX Protocol – Session Layer
UGW
 A Heartbeat Interval must be specified by the firm via the “Logon Request” message,
Gateway
which includes an option to disable client-side heartbeating altogether.
 The value provided by the firm in “SendingTime” (52) is not validated.
Pillar
 A Heartbeat Interval with a value between 1 and 60 seconds must be specified by the
Gateway
firm via the “Logon Request.” One missed heartbeat will result in a test request from
Pillar. Two missed heartbeats will result in an unsolicited logout and closure of the TCP
connection by Pillar.
 “SendingTime” (52) is required on all incoming Session and Application Layer messages,
represented in UTC with millisecond resolution. Pillar will convert the value provided by
the firm to local time and validate that it matches the current business day. If not, the
message will be rejected.
 New – the Exchange will provide the tag “SessionStatus” (1409) on the “Logon Accept”
and “Logout” messages to indicate whether the session is active, logged out, or failed
login due to invalid username/password.
Username/Password Authentication
UGW
 Username and password authentication is not supported.
Gateway
Pillar
 Each session will be assigned a username and password which the firm must specify in
Gateway
their logon request messages.
Inbound Message Throttling
UGW
 Inbound messages are throttled on a per-session basis at a rate of 1000 messages/1
Gateway
rolling second.
Pillar
 Inbound messages are throttled on a per-session basis at a rate of 50 messages/10
Gateway
rolling milliseconds.
 New – outbound Acknowledgments indicate when the corresponding inbound Order,
Cancel/Replace Request, Modify Request, Cancel Request, or Bulk Cancel Request was
throttled – binary “BitfieldFlowIndicator” field; FIX tag “FlowIndicator” (20005).
 New – NYSE Pillar Binary Gateway sessions have an option to specify in the “Login”
request message to reject new inbound Orders when throttled, instead of the default
2
behavior to queue the messages until they can be processed.
o New order messages will be rejected <78 – Throttle Reject >
o Cancel, Modify and Bulk Cancel messages will be processed as if queued
o Cancel portions of Cancel Replace messages will be processed as if queued. The
Exchange will send the following response messages:
 UROUT for the cancelled order with BitfieldFlowIndicator, “Throttled”
bit set to ‘1’ (Inbound Message was Throttled).
 Cancel/Replace Reject with <78 – Throttle Reject>.
o For more details, see the “Pillar Stream Protocol Specification” and the
“Message Throttling” section of the “NYSE Pillar Gateway Binary Protocol
Specification.”
Firm Identifier
UGW
 Firms are identified by their 5 character Equity Trading Permit Identifiers (ETPIDs).
Gateway  The following functions are maintained at the ETPID level:
o Credit limit checks for directed orders and routes to away markets that are not
displaying protected quotations
o Quote Attribution out to XDP feeds
o STP validation
o Exchange Participant ID on OATS Exchange Route Matching
Pillar
 Firms are identified by their 4 character Market Participant Identifiers (MPIDs), and
Gateway
must provide a valid MPID on every Application Layer message sent to the Exchange.
 The following functions are maintained at the MPID level:
o Credit limit checks for directed orders and routes to away markets that are not
displaying protected quotations
o Quote Attribution out to XDP feeds
o STP validation (see separate section below for other changes related to STP
validation
o Exchange Participant ID on OATS Exchange Route Matching
ClOrdID Validation
UGW
 ClOrdID is required to be unique per SenderCompID.
Gateway
Pillar
 ClOrdID is required to be unique for the combination of SenderCompID +
Gateway
OnBehalfOfCompID (FIX), or Username + MPID (Binary). Pillar will validate uniqueness
among open orders only. However, the firm is responsible for ensuring that the ClOrdID
provided is unique among all orders sent for the full length of the trading day by the
given SenderCompID + OnBehalfOfCompID, or Username + MPID.
Symbology
UGW

Gateway
Orders must be entered using Comstock Symbology.
3
Pillar
Gateway


FIX – orders must be entered using NYSE Symbology in “Symbol” (55) and “SymbolSfx”
(65).
Binary – orders must be entered using SymbolID, provided by the Exchange in the
“Equities Symbol Reference Data” message (see section “Binary Protocol – Session
Layer” above). The SymbolIDs provided are the same as those used on the NYSE XDP
market data feeds.
Price Scale (Binary Protocol Only)
UGW
 A price scale must be specified on a message-by-message basis for both inbound and
Gateway
outbound messages.
Pillar
 A fixed price scale of 8 is used on all fields defined with a data type of “Price” (64-bit,
Gateway
unsigned Little Endian) in the NYSE Pillar Gateway Binary Protocol.
Self-Trade Prevention (STP) Validation
UGW
 STP validation happens at the ETPID level.
Gateway
Pillar
 STP validation happens at the MPID level.
Gateway
o Within an MPID a subID can be specified, to allow trades between the same
MPID, as long as the subIDs do not match.
o In FIX, the subID must be specified in “OnBehalfOfSubID” (116).
o In Binary, the subID must be specified in the “MPSubID” field.
 The firm can override the session level default for STP instruction on an order-by-order
basis by providing any other value in the “SelfTradeType” field (in FIX, tag 7928).
*Note: STP across ETPIDs and MPIDs from the same firm will not be validated, and will be allowed to
trade with one another.
Offsets on Market Pegs
UGW
 Supported via the “PegDifference” field (in FIX, tag 211)
Gateway
o For Buy orders, the offset must be specified with a negative number
o For Sell orders, the offset must be specified with a positive number
Pillar
 Supported via the “OffsetPrice” field (in FIX, tag 9403)
Gateway
o For Buy and Sell orders, the offset must be specified as a positive value, which
will be applied as negative offset for buys, and a positive offset for sells
Working Price on Incoming Orders
UGW
 The working price for a new order will be included on every new order
Gateway
acknowledgement in the ”Price” field (in FIX, tag 44).
Pillar
 The working price for a new order will be included in every new order
Gateway
acknowledgement in the “WorkingPrice” field (in FIX, tag 20004).
 The limit price for a new order will be included in every new order acknowledgement in
the “Price” field (in FIX, tag 44).
4
LULD Band Behavior
UGW
 Default behavior is to cancel orders that would execute through the bands.
Gateway  All limit orders may include a discretionary instruction to reprice except:
o If entered with repricing instructions, MPL, MPL ALO, and MPL RPI will not
reprice, but will be held undisplayed until the midpoint of the PBBO is at or
within the LULD bands
 Cross orders priced through an LULD band will reject regardless of repricing instructions
Pillar
 Default behavior is to reprice limit orders that would execute or route through the
Gateway
bands and cancel market orders, Limit IOC and Day ISOs that would execute or route
through the bands.
 Below are exceptions to repricing behavior:
o MPL, MPL ALO, and MPL RPI will not reprice, but will be held undisplayed until
the midpoint of the PBBO is at or within the LULD bands. These orders support
an option to cancel instead by providing a value of “1” in the
“CancelInsteadOfReprice” field (in FIX, tag 20003)
o Cross orders priced through an LULD band will reject regardless of repricing
instructions
 Limit orders support the option to cancel instead of reprice for LULD bands by providing
a value of “1” in the “CancelInsteadOfReprice” field (in FIX, tag 20003)
Cancel/Replace Handling
UGW
 The following fields cannot be change from original order to cancel/replace as they are
Gateway
copied form the original order message:
o ExecInst – cannot change to or from “f” but can change other values
o ExecBroker
o ExtendedExecInst
Pillar
 With the exception of symbol and side from B to S or vice versa, all other fields can be
Gateway
changed from the order to the cancel/replace
Modify Request Handling
UGW
 A Cancel/Replace request which reduces the total number of shares or changes the side
Gateway
of an existing order (between Sell, Sell Short, Sell Short Exempt) is handled in Pillar as a
“Modify Request,” preserving the order’s ranking in the Exchange order book as well as
its original OrderID.
Pillar
 FIX – same as UGW Gateway above.
Gateway  Binary – “Modify Request” is a unique message type, separate from the “Order/Cancel
Replace” message.
5
Defaulting For Tags not Sent by Firms
UGW
 If TimeInForce (in FIX, tag 59) is not provided on an order, it is defaulted to “Day”
Gateway  If trading session (in FIX, tag 336) is not provided on an order, it is defaulted as follows
o For Opening (TIF = 2) and Closing (TIF = 7), trading session is defaulted to Core
o For Market Orders, trading session is defaulted to Core
o For all other order types
 if current session is early or pre-open, trading session will be defaulted
to Early and Core
 if current session is core, trading session will be defaulted to Core
Pillar
 TimeInForce (in FIX, tag 59) must be present on all order messages, and no defaulting
Gateway
will occur
 Trading session (in FIX, tag 336) must be present on all order messages, and no
defaulting will occur
Order Priority Update Ack Message
UGW
 When a reserve order is triggered to replenish, the replenishment will get a new order
Gateway
ID, which is not provided back to the firm via an unsolicited ack.
Pillar
 When a reserve order is triggered to replenish, the replenishment will get a new order
Gateway
ID. On a session, a firm can specify whether or not they would like the corresponding
unsolicited “Priority Update Acknowledgment” for replenishment s on an opt-in/opt-out
basis.
Bulk Cancel Differences
UGW
 Customers specify bulk cancel requests in a cancel message in both Binary and FIX. If an
Gateway
invalid bulk cancel code is provided, the request is treated like a regular cancel message.
Pillar
 Customers specify bulk cancel requests in a Cancel Request message in FIX (OrderID/tag
Gateway
37) and the “Bulk Cancel Request” message in Binary. If an invalid bulk cancel code is
provided, the request will be rejected with “R136: Invalid Bulk Cancel.”
Cancel On Disconnect
UGW
 If enabled, cancellation criteria includes all live and pending orders, excluding MOC/LOC
Gateway
Pillar
 If enabled, cancellation criteria can be either of the options below:
Gateway
o Value of 1 - All live and pending orders excluding auction Orders
(MOO/LOO/MOC/LOC)
o Value of 2 -All live and pending orders
Functionality Supported in Different Fields
UGW
 For Retail program, “RET” is sent in the “SenderSubID” field (in FIX, tag 50).
Gateway  MMID for a Q order is sent in the “SenderSubID” field (in FIX, tag 50).
 Proactive If Locked is supported on routable orders with a value of “Y” in the
“ProactiveIfLocked” field (in FIX, tag 9733).
6


Pillar
Gateway







Non-display remove functionality is supported with a value of “Y” in “ProactiveIfLocked”
field (in FIX, tag 9733) on MPL, MPL ALO, Non-displayed Limit, and Arca Only orders.
Reprice for LULD instead of cancel is supported with a value of “1” or “2” in
“ProactiveIfLocked” field (in FIX, tag 9733).
AttributedQuote is supported in FIX only.
For Retail program
o “RET” is sent in TargetSubID (57) in FIX
o The “RetailIndicator” field is sent as “1” in Binary
MMID on a Q order is sent
o In SenderSubID (50) in FIX
o In “MMID” field in Binary
Proactive If Locked is supported on routable orders with a value of “1” in
“ProactiveIfLocked” field (in FIX, tag 20002).
Non-display remove functionality is supported with a value of “2” in the
“ProactiveIfLocked” field (in FIX, tag 20002) on MPL, MPL ALO, Non-Dispayed Limit, and
Arca Only orders.
Cancel instead of reprice for LULD will be supported with a value of “1” in the
“CancelInsteadOfReprice” field (in FIX, tag 20003) – functionality described in separate
section below).
“AttributedQuote” is supported in both Binary and FIX (20001) – functionality described
in separate section below.
Outgoing Messages
UGW
 Some, but not all, order modifiers and attributes sent by the firm on inbound Order and
Gateway
Cancel/Replace Requests are sent back in Acknowledgements.
 A Cancel, Modify, or Cancel/Replace Request always receives a “pending” message,
even if it can be applied right away.
 Pending Cancel/Replace and Pending Modify Acknowledgments are both represented
with an “OrdStatus” (in FIX, tag 30) of “Pending Cancel/Replace.”
 The “LastMkt” field (in FIX, tag 30) is provided on both FIX and Binary execution reports.
It is populated with a value combining two pieces of information – the NYSE Group
executing market, and the market data Tape (A/B/C) to which the trade is reported.
 FIX protocol only – the following tags are provided on certain outgoing messages:
o AvgPx (6) – on executions.
o OrdRejReason (103) and CxlRejReason (102) – on Order rejects and
Cancel/Cancel-Replace rejects, respectively.
Pillar
 All order modifiers and attributes sent by the firm on inbound Order and Cancel Replace
Gateway
Requests are sent back in Acknowledgments, including on FIX drop copies of the
Acknowledgments.
 A Cancel, Modify, or Cancel/Replace Request will only receive a pending message if it
cannot be applied right away due to market conditions (i.e. auction running or interest
routed away).
 Pending Cancel/Replace and Pending Modify Acknowledgements are distinguished from
each other with separate values. In the binary protocol, this is represented by the
“AckType” field on the “Order Modify/Cancel Request Acknowledgment.” In the FIX
7




ExecID
UGW
Gateway
Pillar
Gateway




protocol, a value of “M” for “Pending Modify” has been added to “OrdStatus” (39) and
ExecType (150).
The “LastMkt” field (in FIX, tag 30) is provided only on FIX execution reports, and not in
Binary (instead, the binary Pillar Stream Protocol “Login” accept message indicates the
MIC of the connected market). In FIX, this tag on executions is populated in accordance
with standard FIX Protocol, with the Market Identification Code (MIC) of the NYSE
Group market that sent the message.
FIX protocol only –
o The following tags are not provided on any outgoing messages: AvgPx (6),
OrdRejReason (103), and CxlRejReason (102).
o On Order, Cancel, Cancel/Replace, and Modify rejects, the Exchange will
provide specific reject codes in the binary “ReasonCode” field and in the FIX tag
“Text” (58).
New – the “Participant Type” field (in FIX, tag 20008) on executions provides
information regarding the executing party’s market participant type (Customer, Market
Maker/LMM, etc.)
New – FIX protocol only – two custom tags, NanosecondSendingTime (20009) and
NanosecondTransactTime (20010) provide UTC timestamps with nanosecond resolution
on outgoing messages. These tags provide the same data points as the standard FIX
Header tags SendingTime (52) and TransactTime (60), with more granularity. The
Exchange provides all four tags on all outgoing messages in the NYSE Pillar FIX Gateway.
Populated on fills, partial fills, busts, and corrections, with the following concatenated
values, GTCIndicator + SystemID + MarketID + DealID of the trade. This will be provided
to both sides of a trade
o In FIX, the unsigned 64 bit representation is copied to the appropriate fields as
an ASCII string
o In Binary, the unsigned 64 bit representation will be translated into the correct
Binary Format for the appropriate field length
On any other message, where ExecID field is present, the value will be zero
Will be populated in FIX on all MsgType = 8 messages with a string of up to 32
characters (alphanumeric), which is globally unique.
In Binary, this field will not be provided, but each response message has its own
SeqMsgID, which is globally unique.
FIX Drop Copy Configuration
UGW
 Drop copy messages are delivered in FIX 4.0 format.
Gateway  Message filters consist of ETPID and All Message Activity, All Except Done for
Day/Rejects/Billable Cancels, or Fills/Partial Fills only.
 Drop copy sessions may be configured to receive copies of inbound Order messages, in
addition to outgoing Order Acknowledgments. Order Acks do not include all the tags
from the inbound Orders.
Pillar
 Both order entry and drop copy sessions are configured with FIX 4.2, and drop copy
Gateway
8




messages are delivered in FIX 4.2. For FIX order entry sessions with corresponding FIX
drop copy sessions, the original messages and the drop copy messages are identical in
format (see “Execution Report”/MsgType = 8 in the “NYSE Pillar Gateway FIX Protocol
Specification”).
Message filters consist of SenderCompID(s), MPID(s) or ClearingAccount, and either All
Message Activity or Fills/Partial Fills Only.
Drop copy sessions may be configured to receive copies of outgoing Order
Acknowledgments only, and not copies of inbound Orders. Order Acks include all the
tags from the inbound Orders.
New – for Binary order entry sessions with corresponding FIX drop copy sessions, the
outgoing binary message can be mapped to the outgoing FIX drop copy message using
order and message sequence number identifiers. For details, see the “FIX Drop Copies”
section of the “NYSE Pillar Gateway Binary Protocol Specification.”
New – drop copy gateways for order activity transacted on UGW are separate from
drop copy gateways for order activity transacted on Pillar Gateway.
Failure Recovery
UGW
 Each session is configured with one IP address. In the event of a gateway failure, the
Gateway
affected sessions are moved to a cold backup that assumes the IP addresses of the
primary sessions. Firms experience an interruption of service during the recovery
process.
Pillar
 Each session is configured with two pairs of destination Pillar IP addresses, all sharing
Gateway
the same port number. Two IPs correspond to the Pillar Primary Production
environment and the other two IPs to the DR Production environment, which become
active only if the Primary is unavailable. Within the active production environment, the
pair of IP addresses is synchronized to the same session data at all times.
o In the event that one IP destination becomes unavailable, the firm may log in
(FIX) or request write access to the streams (binary) on the second IP
destination.
o During the failover, cancel on disconnect will be triggered subject to the Cancel
on Disconnect configuration for the session. Because the two IP destinations are
synchronized at all times, message state and sequence numbers are preserved
and gap fill can occur on the second IP destination.
o For more details, see the “Failure Recovery” section of the Pillar Gateway FIX or
Binary Protocol Specifications.
Pre Liquidity Indicator on Ack Messages
UGW
 In the “LiquidityIndicator” field (in FIX, tag 9730), the firm can receive the following
Gateway
values
o 1 – candidate to set internal BBO
o 2 – working price different than display price
o 3 – working price same as display price
Pillar
 Details as to whether or not an order was a candidate to set the internal BBO at its
Gateway
display price will be specified in
o “LiquidityIndicator” tag in FIX (9730)
9
o
o

“PreLiquidityIndicator” field in Binary
Values are as follows:
 1 – candidate to set internal BBO
 0 – not a candidate to set internal BBO
Details about working price relative to display price will be available in the
“WorkingAwayFromDisplay” field (in FIX, tag 20006):
o 1 – working price = display price
o 2 – working price not equal to display price
Liquidity Indicator Changes – the table below show the new codes firms will receive on executions in
the “LiquidityIndicator” field (in FIX, tag 9730) in the Pillar Gateway with a comparison to the old codes
in UGW Gateway.
Definition
Executions Adding Liquidity (Non-Auction)
Add Regular Limit Order
Add Sub Dollar Execution
Add MPL Order
Add Non-Displayed Limit Order
Add Arca/NYSE Only -Working at different price than
display price at time of execution
Add Tracking Order
Add Limit Order Setting New BBO
Add Retail Provider
Add Retail Provider RPI Order
Add MPL Retail Provider
Executions Removing Liquidity (Non-Auction)
Remove Regular Limit or Market
Remove Sub Dollar
Remove MPL Order
Remove Non-Displayed Limit Order
Remove Retail Taker Order (RT1, RT2)
Remove MPL Retail Taker
Executions in Opening/Re-Opening Auctions
Market Day, MOO, LOO Executions
Limit orders
All Sub-Dollar Executions
Execution in Closing Auctions
Market Day, MOC, LOC Executions
Limit orders
10
UGW
Gateway
Pillar
Gateway
A
D
M
O
A
AZ
AML
AND
B
J
S
A
I
I
AB
AT
ASB
ARE
ARP
ARM
R
E
L
R
K
R
R
RZ
RML
RND
RRT
RRM
G
O
E
O
OL
OZ
Z
O
C
CL
Definition
Sub Dollar All Executions
Executions on Routed Orders
Routed – NYSE Execution
Routed – NYSE MKT Execution
Routed to NYSE Opening/Reopening Auction
Routed to NYSE MKT Opening/ Reopening Auction
Routed – Away Market Execution, Non- NYSE Group
Routed – NYSE Sub Dollar
Routed – NYSE MKT Sub Dollar
Routed – Away Market Sub Dollar, Non- NYSE Group
Primary Only to NYSE
Primary Only Executed in Opening/Reopening
Primary Only Adding Liquidity
Primary Only Removing Liquidity
Primary Only Routed from Primary
Primary Only MOC/LOC
945/355 Executed on Primary
Primary Only Sub Dollar
Primary Only to NYSE MKT
Primary Only Executed in Opening/Reopening
Primary Only Adding Liquidity
Primary Only Removing Liquidity
Primary Only Routed from Primary
Primary Only MOC/LOC
945/355 Executed on Primary
Primary Only Sub Dollar
Primary Only to Away Market, Non- NYSE Group
Primary Only Adding/Removing Liquidity
945/355 Executed on Primary
Primary Only Sub Dollar
Cross Order Execution
Limit IOC Cross (Cross Execution only)
UGW
Gateway
Pillar
Gateway
E
CZ
N
N
C
C
X
H
H
H
XN
XA
XNO
XAO
X
XNZ
XAZ
XZ
C
F
N
W
U
N
H
XNO
XNA
XN
XNW
XNC
XNT
XNZ
C
F
N
W
Y
N
H
XAO
XAA
XA
XAW
XAC
XAT
XAZ
X
X
H
XDA
XDT
XDZ
O
Z
Functionality that will not be supported in Pillar Gateway:

Defaults for the following fields for inbound messages (both FIX and Binary):
o Proactive if Locked
o ExtendedExecInst
11

Defaults for outbound filtering of tags in FIX:
o Send ArcaExID
o Send Liquidity Indicator
o Send Bust and Correct
o Send ExecBroker

Sell Short No slide will not be supported for Pillar Gateway, and will be eliminated for UGW
(both FIX and Binary)
Document Version History
Date
Document Version #
October 28, 2016
1.0
December 8, 2016
1.1
January 5, 2017
1.2
February 23, 2017
1.3
April 12, 2017
1.4
Change Summary
Initial version of the document.
Updated the following sections:
“FIX Protocol – Message Sequence Numbers” – for Pillar
Gateway, replaced details on PossDup and PossResend with
a reference to the NYSE Pillar Gateway FIX Protocol
Specification, which provides the updated information.
“ClOrdID Validation” – for Pillar Gateway (FIX), updated
details about uniqueness validation.
Updated the following sections:
“FIX Drop Copy Configuration” – added detail regarding
separate gateway instances for drop copies of UGW order
activity vs. Pillar Gateway order activity.
“Functionality Supported in Different Fields” – corrected tags
for RET and MMID designation in Pillar Gateway.
Updated the following sections to reflect recent changes to the Pillar
Binary Protocol which added support for a user defined ClOrdID on all
inbound messages:
“Binary Protocol – Session Layer”
“ClOrdID Validation”
Added OATS detail to section “Firm Identifier.”
12
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising