FPL Exchanges / ECN Working Group
Recommendations – Part 1
July 2006
Co-Chairs:
Matt Simpson, Chicago Mercantile Exchange (Americas Representative)
Kathleen Grey, HSBC (Asia-Pacific/Japan Representative)
Hanno Klein, Deutsche Börse (EMEA Representative)
Mission Statement
The mission of FPL’s Exchanges/ECN Working Group (ExWG) is to
enable and promote the harmonized usage of FIX by exchanges
and ECNs for the major asset classes of equities, derivatives, fixed
income and foreign exchange markets. The working group will seek
to reduce redundancies in the interest of achieving optimal
performance and to remove ambiguities to attain true
standardization for firms accessing multiple exchanges via FIX.
2
Scope Definition

The following topics are discussed in detail together with examples
for different possible behaviors and templates to define best
practices and give recommendations









Order Lifetime
Order Identification
Order Modification
Order Entry and Modification from Different Sources
Order Rejections
Message Bundling
Pending Order States
Restatement of Orders
Corporate Actions
3
Topic









Order Lifetime
Order Identification
Order Modification
Order Entry and Modification from Different Sources
Order Rejections
Message Bundling
Pending Order States
Restatement of Orders
Corporate Actions
4
Order Lifetime





The lifetime of an order ends when all or partial information about an
order is no longer accessible through the interface.
FIX does not foresee the sell-side to end the lifetime without an
explicit request from the buy-side to cancel it. Even then, the buyside can still access this order through a number of FIX requests.
Some exchanges restrict the lifetime of an order to its existence in
the book of active, i.e. executable orders.
During order modification for change of price or increase of quantity,
some exchanges will automatically end the lifetime of the order and
issue a new one.
Guidelines are relevant for the following issues:


Status request for filled orders (A)
Modification of filled orders (B)
5
Order Lifetime (cont.)

Status request for filled orders (A)



Model A1: Return ExecutionReport with status and quantity information
for orders of current business day
Model A2: Reject status request in the same way as an invalid order
identification
Modification request for filled orders (B)


Model B1: Accept increase of order quantity and set order status back to
“partially filled”
Model B2: Reject modification request in the same way as an invalid
order identification
6
Order Lifetime: Status Request for Filled Orders (A-A1/A2)
Time
Message Received
(ClOrdID,
OrigClOrdID)
1
New Order(X)
Message Sent
(ClOrdID,
OrigClOrdID)
Exchange
(OrderID,
OrigOrderID)
Exec
Type
Ord
Status
Order
Qty
Cum
Qty
Leaves
Qty
Comment
Exchange issues A as OrderID
10,000
2
Execution(X)
A
New
New
10,000
0
10,000
3
Execution (X)
A
Trade
Filled
10,000
10,000
0
4
Status Request(X)
5
A
Execution (X)
A
Execution for 10,000
Request for information
Order
Status
Filled
10,000
10,000
0
Order has been completely filled
with a quantity of 10,000
Model A1: Return ExecutionReport with status and quantity information for orders
of current business day
Time
Message Received
(ClOrdID,
OrigClOrdID)
1
New Order(X)
Message Sent
(ClOrdID,
OrigClOrdID)
Exchange
(OrderID,
OrigOrderID)
Exec
Type
Ord
Status
Order
Qty
Cum
Qty
Leaves
Qty
Comment
Exchange issues A as OrderID
10,000
2
Execution(X)
A
New
New
10,000
0
10,000
3
Execution (X)
A
Trade
Filled
10,000
10,000
0
4
5
Status Request(X)
A
Execution (X)
A
Execution for 10,000
Request for information
Order
Status
Rejected
0
0
0
OrdRejReason = unknown order
Model A2: Reject status request in the same way as an invalid order identification
7
Order Lifetime: Modification Request for Filled Orders (B-B1/B2)
Time
Message Received
(ClOrdID,
OrigClOrdID)
1
New Order(X)
Message Sent
(ClOrdID,
OrigClOrdID)
Exchange
(OrderID,
OrigOrderID)
Exec
Type
Ord
Status
Order
Qty
Cum
Qty
Leaves
Qty
Comment
Exchange issues A as OrderID
10,000
2
Execution(X)
A
New
New
10,000
0
10,000
3
Execution (X)
A
Trade
Filled
10,000
10,000
0
4
Replace
Request(Y,X)
5
12,000
A
Execution (Y,X)
B, A
Replace
Partially
Filled
12,000
Execution for 10,000
Request to increase total order qty
from 10,000 to 12,000
10,000
2,000
Order has been completely filled
with a quantity of 10,000
Model B1: Accept increase of order quantity and sets order status back to “partially
filled” (order identification model E1)
Time
Message Received
(ClOrdID,
OrigClOrdID)
1
New Order(X)
Message Sent
(ClOrdID,
OrigClOrdID)
Exchange
(OrderID,
OrigOrderID)
Exec
Type
Ord
Status
Order
Qty
Cum
Qty
Leaves
Qty
Comment
Exchange issues A as OrderID
10,000
2
Execution(X)
A
New
New
10,000
0
10,000
3
Execution (X)
A
Trade
Filled
10,000
10,000
0
4
5
Replace
Request(Y,X)
12,000
A
Execution (Y,X)
B, A
Replace
Rejected
12,000
Execution for 10,000
Request to increase total order qty
from 10,000 to 12,000
0
0
OrdRejReason = unknown order,
order quantity is echoed back
Model B2: Reject modification request in the same way as an invalid order
identification (order identification model E1)
8
Order Lifetime - Recommendation

Issues:



Best Practices:



Status request for filled orders (A1, A2)
Modification of filled orders (B1, B2)
A1 – return order status and quantity for filled orders
B2 – reject modification of filled orders
Additional guidelines and comments:





Scope of A1 should be restricted, e.g. to the current business day
A1 might not deliver the best performance compared with A2 but is significantly
more user friendly
A2 has the drawback that it cannot differentiate between orders that have been
filled, cancelled or that have never existed
B1 might be useful in environments with high (manual) effort to create new order
A1 and B2 can also apply to orders that have been cancelled or that have expired
9
Topic









Order Lifetime
Order Identification
Order Modification
Order Entry and Modification from Different Sources
Order Rejections
Message Bundling
Pending Order States
Restatement of Orders
Corporate Actions
10
Order Identification





FIX knows order identification fields coming from the buy-side
(ClOrdID) as well as from the sell side (OrderID)
Buy-side order identification (ClOrdID) is typically mandatory, needs
to be changed when modifying the order and must be unique (at
least for the current business day)
OrderID is typically optional and does not need to change during the
order lifetime
Exchanges issue their own order identification (OrderID) and often
require this information for any subsequent actions on this order
Guidelines are relevant for the following issues:



Mandatory vs. optional nature of ClOrdID and OrderID (C)
Enforcement of ClOrdID uniqueness by the exchange (D)
Persistence of exchange issued order identification (E)
11
Order Identification (cont.)

Mandatory vs. optional nature of ClOrdID and OrderID (C)





Enforcement of ClOrdID uniqueness by the exchange (D)



Model C1: ClOrdID is mandatory, OrderID is unused or used for first
ClOrdID
Model C2: ClOrdID is mandatory, OrderID is optional
Model C3: ClOrdID is optional, OrderID is mandatory
Model C4: ClOrdID and OrderID are conditionally required
Model D1: Check ClOrdID and reject orders with duplicate values
Model D2: Do not check ClOrdID and treat orders with duplicate values
as separate entities
Persistence of exchange issued order identification (E)


Model E1: Issue single order identification and optionally change it
during the lifetime of an order
Model E2: Issue two order identifications (private/static and public/
dynamic) whereby private one does not change
12
Order Identification: Enforcement of ClOrdID Uniqueness by the Exchange (D-D1/D2)
Time
Message Received
(ClOrdID,
OrigClOrdID)
1
New Order(X)
2
3
New Order(X)
Time
1
New Order(X)
2
Message Sent
(ClOrdID,
OrigClOrdID)
Order
Qty
Cum
Qty
Leaves
Qty
Comment
A
New
New
A
10,000
0
10,000
Exchange issues A as OrderID
12,000
Rejected
New
10,000
Second order carries the same
ClOrdID
1,000
9,000
OrdRejReason = duplicate order,
current status and quantities of
existing order are returned
Exchange
(OrderID,
OrigOrderID)
Exec
Type
Ord
Status
Order
Qty
Cum
Qty
Leaves
Qty
Comment
10,000
Execution(X)
New Order(X)
Model D2:
Ord
Status
Check ClOrdID and reject orders with duplicate values
Message Received
(ClOrdID,
OrigClOrdID)
4
Exec
Type
A
Execution (X)
Model D1:
Exchange
(OrderID,
OrigOrderID)
10,000
Execution(X)
4
3
Message Sent
(ClOrdID,
OrigClOrdID)
A
New
New
B
0
10,000
12,000
A
Execution (X)
10,000
New
New
12,000
Exchange issues A as OrderID of
first new order
Second order carries the same
ClOrdID
0
12,000
Exchange issues B as OrderID of
second new order
Do not check ClOrdID and treat orders with duplicate values as separate entities
13
Order Identification: Persistence of Exchange Issued Order Identification (E-E1)
Time
Message Received
(ClOrdID,
OrigClOrdID)
1
New Order(X)
Message Sent
(ClOrdID,
OrigClOrdID)
Exchange
(OrderID,
OrigOrderID)
Exec
Type
Ord
Status
Order
Qty
Cum
Qty
Leaves
Qty
Comment
Exchange issues A as OrderID
10,000
2
Execution(X)
A
New
New
10,000
0
10,000
3
Execution (X)
A
Trade
Partially
Filled
10,000
1,000
9,000
4
Replace
Request(Y,X)
12,000
A
5
Execution (Y,X)
6
Execution (Y)
B, A
B
Execution for 1,000
Request to increase total order qty
from 10,000 to 12,000
Replace
Partially
Filled
12,000
1,000
11,000
Order continues to exist with an
executed quantity of 1,000, client
order ID changes from X to Y,
exchange order ID changes from A
to B
Trade
Partially
Filled
12,000
2,000
10,000
Execution for 1,000
Model E1: Issues single order identification and optionally change it during
the lifetime of an order
14
Order Identification: Persistence of Exchange Issued Order Identification (E-E2)
Time
Message Received
(ClOrdID,
OrigClOrdID)
1
New Order(X)
Message Sent
(ClOrdID,
OrigClOrdID)
Exchange
(OrderID,
OrigOrderID,
SecondaryOrderID)
Exec
Type
Ord
Status
Order
Qty
Cum
Qty
Leaves
Qty
10,000
2
Execution(X)
A, -, N
New
New
10,000
0
10,000
3
Execution (X)
A, -, N
Trade
Partially
Filled
10,000
1,000
9,000
4
Comment
Replace
Request(Y,X)
12,000
A/-/N
Exchange issues A as public/
dynamic order ID and N as private/
static order ID
Execution for 1,000
Request to increase total order qty
from 10,000 to 12,000. Sender uses
either static value N or current public
value A to identify order.
5
Execution (Y,X)
B, A, N
Replace
Partially
Filled
12,000
1,000
11,000
Order continues to exist with an
executed quantity of 1,000, client
order ID changes from X to Y,
public/dynamic exchange order ID
changes from A to B, private
exchange order ID N does not
change
6
Execution (Y)
B, -, N
Trade
Partially
Filled
12,000
2,000
10,000
Execution for 1,000
Model E2: Issue two order identifications (private/static and public/dynamic)
whereby private one does not change
15
Order Identification - Recommendation

Issues:




Best Practices:




Mandatory vs. optional nature of ClOrdID and OrderID (C1, C2, C3, C4)
Enforcement of ClOrdID uniqueness by the exchange (D1, D2)
Persistence of exchange issued order identification (E1, E2)
C4: ClOrdID and OrderID conditionally required
D2: ClOrdID uniqueness not enforced by exchange
E2: Issue two order identifications
Additional guidelines and comments:





Usage of ClOrdID might not deliver the best performance compared with OrderID but is more
user friendly and allows modification and deletion of orders prior to the order entry being
confirmed.
D1 increases latency if exchange internally uses OrderID but can be considered best practice
when offered as an optional service.
Scope of uniqueness (current day, single security, active orders) for D1 depends on exchange
architecture and makes specific recommendation impractical.
Potential misuse of model D1 when member firms can resend order entries without having to
consider duplicates.
In order to avoid dependencies, order identification tags should not be used for ranking
purposes of matching algorithms supporting price/time priority.
16