Market on close orders pre-assignment

[carloshernandez18_x]

Imported from previous forum

[carloshernandez18_x]

Hi All:

I’m studying the case of a exchange that follows this protocol to match market on close orders:

1. Two orders, one for buy 1000 @ market close and one for sell 500 @ market close are received
2. the buy & sell are matched and each party is informed that 500 shares are ‘pre-assigned’ to the other party. No price or ExecId are created
3. the buyer can only cancel now up to 500 shares. The seller cannot cancel anything.
4. At the end of the day, the pre-assignments turn into real matches and the buyer and seller now get an execution report, together with price, execId, etc.

The above is not in FIX at the moment, and I am struggling with the modeling of the pre-assignment concept. Does anyone know a similar problem or have ideas on possible FIX models for it?

Regards

-C

[hanno.klein]

Carlos,

interesting case but I do not see why it should not be covered by FIX. FIX requires to send back an ExecID in the ExecutionReport but not a price (e.g. in case of a market order). ExecID is a simple message identifier and not an identifier for a match/fill. You would need to use the 58 Text field to convey pre-assignment information about the order. The order status does not need to change.

I find it strange that you should not be able to modify or delete your order and that it gets pre-matched. Anything can happen between time of entry and market close. Why would you force someone to match at whatever price the market eventually closes?

A message flow that will be proposed as an extension to FIX shortly might be able to cover your scenario, i.e. locked orders which are subject to restrictions related to modifications/deletions (governed by Rules of Engagement). You would then be able to send back an ExecutionReport with a locked quantity and a lock type (e.g. “Pre-matched”) to the order submitter to tell him that part of his order is no longer (or only currently not) accessible. There is already a user-defined field 7770 LockedQty. The lock type is not really covered, the closest are 9847 LockedInStatus and 9857 LockedIn but the intended semantic differs.

Please join the next meeting of the Global Exchanges & Markets Committee on Monday, August 9 at 9am ET where the extension for locked (and released) orders will be presented and discussed.

Regards,
Hanno.

Hi All:

I’m studying the case of a exchange that follows this protocol to match market on close orders:

1. Two orders, one for buy 1000 @ market close and one for sell 500 @ market close are received
2. the buy & sell are matched and each party is informed that 500 shares are ‘pre-assigned’ to the other party. No price or ExecId are created
3. the buyer can only cancel now up to 500 shares. The seller cannot cancel anything.
4. At the end of the day, the pre-assignments turn into real matches and the buyer and seller now get an execution report, together with price, execId, etc.

The above is not in FIX at the moment, and I am struggling with the modeling of the pre-assignment concept. Does anyone know a similar problem or have ideas on possible FIX models for it?

Regards

-C

[kaymahes_x]

Hanno,

My understanding was that Market on close orders are queued up and not added to the active order book, when the market closes, these orders are processed in the order in which they were received. So order submitter would have the ability to cancel-replace their order but they could loose position in the queue or cancel the order entirely before the market closes.

If this new proposed Locked order workflow is implemented, I would propose addition of a new DoNotLock boolean tag (number to be decided) to order messages to indicate that the order submitter would not want any locking on the order and wants to be able to cancel / cancel-replace it.

Could this locking workflow be also applicable to Market on open as well?

Carlos,

interesting case but I do not see why it should not be covered by FIX. FIX requires to send back an ExecID in the ExecutionReport but not a price (e.g. in case of a market order). ExecID is a simple message identifier and not an identifier for a match/fill. You would need to use the 58 Text field to convey pre-assignment information about the order. The order status does not need to change.

I find it strange that you should not be able to modify or delete your order and that it gets pre-matched. Anything can happen between time of entry and market close. Why would you force someone to match at whatever price the market eventually closes?

A message flow that will be proposed as an extension to FIX shortly might be able to cover your scenario, i.e. locked orders which are subject to restrictions related to modifications/deletions (governed by Rules of Engagement). You would then be able to send back an ExecutionReport with a locked quantity and a lock type (e.g. “Pre-matched”) to the order submitter to tell him that part of his order is no longer (or only currently not) accessible. There is already a user-defined field 7770 LockedQty. The lock type is not really covered, the closest are 9847 LockedInStatus and 9857 LockedIn but the intended semantic differs.

Please join the next meeting of the Global Exchanges & Markets Committee on Monday, August 9 at 9am ET where the extension for locked (and released) orders will be presented and discussed.

Regards,
Hanno.

Hi All:

I’m studying the case of a exchange that follows this protocol to match market on close orders:

1. Two orders, one for buy 1000 @ market close and one for sell 500 @ market close are received
2. the buy & sell are matched and each party is informed that 500 shares are ‘pre-assigned’ to the other party. No price or ExecId are created
3. the buyer can only cancel now up to 500 shares. The seller cannot cancel anything.
4. At the end of the day, the pre-assignments turn into real matches and the buyer and seller now get an execution report, together with price, execId, etc.

The above is not in FIX at the moment, and I am struggling with the modeling of the pre-assignment concept. Does anyone know a similar problem or have ideas on possible FIX models for it?

Regards

-C

[hanno.klein]

Yes, these are not part of the active orders. The process described by Carlos is not one where the user can choose whether his order gets locked or not. Locking is something triggered by the Rules&Regs of the marketplace. An order submitter would not want his order to be restricted (locked) on purpose.

Hanno,

My understanding was that Market on close orders are queued up and not added to the active order book, when the market closes, these orders are processed in the order in which they were received. So order submitter would have the ability to cancel-replace their order but they could loose position in the queue or cancel the order entirely before the market closes.

If this new proposed Locked order workflow is implemented, I would propose addition of a new DoNotLock boolean tag (number to be decided) to order messages to indicate that the order submitter would not want any locking on the order and wants to be able to cancel / cancel-replace it.

Could this locking workflow be also applicable to Market on open as well?

Carlos,

interesting case but I do not see why it should not be covered by FIX. FIX requires to send back an ExecID in the ExecutionReport but not a price (e.g. in case of a market order). ExecID is a simple message identifier and not an identifier for a match/fill. You would need to use the 58 Text field to convey pre-assignment information about the order. The order status does not need to change.

I find it strange that you should not be able to modify or delete your order and that it gets pre-matched. Anything can happen between time of entry and market close. Why would you force someone to match at whatever price the market eventually closes?

A message flow that will be proposed as an extension to FIX shortly might be able to cover your scenario, i.e. locked orders which are subject to restrictions related to modifications/deletions (governed by Rules of Engagement). You would then be able to send back an ExecutionReport with a locked quantity and a lock type (e.g. “Pre-matched”) to the order submitter to tell him that part of his order is no longer (or only currently not) accessible. There is already a user-defined field 7770 LockedQty. The lock type is not really covered, the closest are 9847 LockedInStatus and 9857 LockedIn but the intended semantic differs.

Please join the next meeting of the Global Exchanges & Markets Committee on Monday, August 9 at 9am ET where the extension for locked (and released) orders will be presented and discussed.

Regards,
Hanno.

Hi All:

I’m studying the case of a exchange that follows this protocol to match market on close orders:

1. Two orders, one for buy 1000 @ market close and one for sell 500 @ market close are received
2. the buy & sell are matched and each party is informed that 500 shares are ‘pre-assigned’ to the other party. No price or ExecId are created
3. the buyer can only cancel now up to 500 shares. The seller cannot cancel anything.
4. At the end of the day, the pre-assignments turn into real matches and the buyer and seller now get an execution report, together with price, execId, etc.

The above is not in FIX at the moment, and I am struggling with the modeling of the pre-assignment concept. Does anyone know a similar problem or have ideas on possible FIX models for it?

Regards

-C

[kaymahes_x]

Hanno,

I agree an order submitter would not want his order to be restricted (locked) on purpose. So I wanted to give the order submitter flexibility to say “do not lock my order”. I am looking at FIX connections as below

Investment <—> Smart <—> Market-1
Bank Order
router <—> Market-2

                            <--->    Market-3

There are securities which trade on multiple markets.

A buy side is connected to a Broker’s smart order router.

Smart Order router connects to multiple markets.

Market-1 has locking workflow

Market-2 and 3 do not have locking restriction.

Buy side sends a Market on close order with new Tag LockableOrder=N to smart order router for a security which trades on these three markets. The smart order router would exclude Market-1 from the matching markets because of conflicting rules : Market-1 implements locking workflow but this order is not lockable. So based on some other rule this order would get routed to market 2 or 3 only. Is this a valid usecase?

Regards,
K. Mahesh

Yes, these are not part of the active orders. The process described by Carlos is not one where the user can choose whether his order gets locked or not. Locking is something triggered by the Rules&Regs of the marketplace. An order submitter would not want his order to be restricted (locked) on purpose.

Hanno,

[hanno.klein]

I do not see the use case and it does not reflect the business requirements of a lock/release concept for orders in a best execution environment that will be subject to discussion in the GExMC next week.

The original topic was Market on Close orders and not locking. It was about the requirement to communicate back to the submitter that his order has been pre-assigned.

FIX extensions should always be based on gaps between existing/planned practices of members of the FIX community and the current FIX spec. It should also apply to more than one marketplace or user to warrant standardization. This may be the case in your scenario but I have not come across it before.

Hanno,

I agree an order submitter would not want his order to be restricted (locked) on purpose. So I wanted to give the order submitter flexibility to say “do not lock my order”. I am looking at FIX connections as below

Investment <—> Smart <—> Market-1
Bank Order
router <—> Market-2

                            <--->    Market-3

There are securities which trade on multiple markets.

A buy side is connected to a Broker’s smart order router.

Smart Order router connects to multiple markets.

Market-1 has locking workflow

Market-2 and 3 do not have locking restriction.

Buy side sends a Market on close order with new Tag LockableOrder=N to smart order router for a security which trades on these three markets. The smart order router would exclude Market-1 from the matching markets because of conflicting rules : Market-1 implements locking workflow but this order is not lockable. So based on some other rule this order would get routed to market 2 or 3 only. Is this a valid usecase?

Regards,
K. Mahesh

Yes, these are not part of the active orders. The process described by Carlos is not one where the user can choose whether his order gets locked or not. Locking is something triggered by the Rules&Regs of the marketplace. An order submitter would not want his order to be restricted (locked) on purpose.

Hanno,

[carloshernandez18_x]

Hanno,

Thank you so much for your response! it is indeed strange that you can’t modify the order despite being just a pre-allocation.

Based on your suggestions, I feel the following behavior could be a clean FIX implementation:

1. Two orders, one for buy 1000 @ market close and one for sell 500 @ market close are received
2. the buy & sell are matched and each party is informed that 500 shares are ‘pre-assigned’ to the other party. An ExecutionReport is sent with no price but ExecId=E1 and LockedQty[7770] and LockedInStatus[9487] to indicate that is a pre-assignment.
3. the buyer can only cancel now up to 500 shares. The seller cannot cancel anything.
4. At the end of the day, the pre-assignments turn into real matches and the buyer and seller get an execution report where ExecTransType[20]=Correction, the correct Price is sent and RefExecId=A1

This way a FIX compliant OMS could process the order correctly, even if it does not take in account the pre-allocation tags.

Warm regards

-C

Carlos,

interesting case but I do not see why it should not be covered by FIX. FIX requires to send back an ExecID in the ExecutionReport but not a price (e.g. in case of a market order). ExecID is a simple message identifier and not an identifier for a match/fill. You would need to use the 58 Text field to convey pre-assignment information about the order. The order status does not need to change.

I find it strange that you should not be able to modify or delete your order and that it gets pre-matched. Anything can happen between time of entry and market close. Why would you force someone to match at whatever price the market eventually closes?

A message flow that will be proposed as an extension to FIX shortly might be able to cover your scenario, i.e. locked orders which are subject to restrictions related to modifications/deletions (governed by Rules of Engagement). You would then be able to send back an ExecutionReport with a locked quantity and a lock type (e.g. “Pre-matched”) to the order submitter to tell him that part of his order is no longer (or only currently not) accessible. There is already a user-defined field 7770 LockedQty. The lock type is not really covered, the closest are 9847 LockedInStatus and 9857 LockedIn but the intended semantic differs.

Please join the next meeting of the Global Exchanges & Markets Committee on Monday, August 9 at 9am ET where the extension for locked (and released) orders will be presented and discussed.

Regards,
Hanno.

Hi All:

I’m studying the case of a exchange that follows this protocol to match market on close orders:

1. Two orders, one for buy 1000 @ market close and one for sell 500 @ market close are received
2. the buy & sell are matched and each party is informed that 500 shares are ‘pre-assigned’ to the other party. No price or ExecId are created
3. the buyer can only cancel now up to 500 shares. The seller cannot cancel anything.
4. At the end of the day, the pre-assignments turn into real matches and the buyer and seller now get an execution report, together with price, execId, etc.

The above is not in FIX at the moment, and I am struggling with the modeling of the pre-assignment concept. Does anyone know a similar problem or have ideas on possible FIX models for it?

Regards

-C

[hanno.klein]

Carlos,

sounds good, a few more comments and issues to consider:

• You did not say which ExecType value you would want to use. You would need to send a price if sent as a fill (FIX 4.2 ExecType 1 or 2). Maybe it is better to send it as a restatement (ExecType D) and populate the lock fields to indicate the pre-assignment. The lock fields can be removed again at the end of the day when confirming the trade (unless you have multiple pre-assignments, i.e. your locked qty only gets reduced until it is finally zero)
• Apart from the technical issue (price needed for ExecType conveying a fill), there might be a business reason to not send a trade until it is actually done at the end of the day. What if the market is halted for some reason and “on close” orders are removed?
• Filled orders are considered to be in a terminal state (at least by exchanges) and fall out of the pool of active orders. You might not be able to inquire the order anymore (in your case the sell order for 500). Keeping the order state “New” avoids this problem.
• Modifications of “on close” orders (if permitted) need to take the locked qty into account and be rejected if the new qty falls below the locked qty (in your example, changing 1000 to less than 500)
• If you DO send out the pre-assignment as a trade: you described FIX 4.2 where ExecTransType is still valid. As of FIX 4.3 this field is deprecated and it would be just ExecType = G = Trade Correct instead.
• I will add another value “Pre-Assignment Lock” to the intended new standard field LockType (subject to committee discussion and approval)

Regards,
Hanno.

Hanno,

Thank you so much for your response! it is indeed strange that you can’t modify the order despite being just a pre-allocation.

Based on your suggestions, I feel the following behavior could be a clean FIX implementation:

1. Two orders, one for buy 1000 @ market close and one for sell 500 @ market close are received
2. the buy & sell are matched and each party is informed that 500 shares are ‘pre-assigned’ to the other party. An ExecutionReport is sent with no price but ExecId=E1 and LockedQty[7770] and LockedInStatus[9487] to indicate that is a pre-assignment.
3. the buyer can only cancel now up to 500 shares. The seller cannot cancel anything.
4. At the end of the day, the pre-assignments turn into real matches and the buyer and seller get an execution report where ExecTransType[20]=Correction, the correct Price is sent and RefExecId=A1

This way a FIX compliant OMS could process the order correctly, even if it does not take in account the pre-allocation tags.

Warm regards

-C

[kaymahes_x]

Hanno,

What order status would you reccomend for a “pre-assignment locked” fill ? Would we need a new order status or would OrderStatus=PartiallyFilled / Filled suffice for this because at market close these preassigned / locked orders would anyway be partfilled / filled ?

Regards,
K. Mahesh

Carlos,

sounds good, a few more comments and issues to consider:

• You did not say which ExecType value you would want to use. You would need to send a price if sent as a fill (FIX 4.2 ExecType 1 or 2). Maybe it is better to send it as a restatement (ExecType D) and populate the lock fields to indicate the pre-assignment. The lock fields can be removed again at the end of the day when confirming the trade (unless you have multiple pre-assignments, i.e. your locked qty only gets reduced until it is finally zero)
• Apart from the technical issue (price needed for ExecType conveying a fill), there might be a business reason to not send a trade until it is actually done at the end of the day. What if the market is halted for some reason and “on close” orders are removed?
• Filled orders are considered to be in a terminal state (at least by exchanges) and fall out of the pool of active orders. You might not be able to inquire the order anymore (in your case the sell order for 500). Keeping the order state “New” avoids this problem.
• Modifications of “on close” orders (if permitted) need to take the locked qty into account and be rejected if the new qty falls below the locked qty (in your example, changing 1000 to less than 500)
• If you DO send out the pre-assignment as a trade: you described FIX 4.2 where ExecTransType is still valid. As of FIX 4.3 this field is deprecated and it would be just ExecType = G = Trade Correct instead.
• I will add another value “Pre-Assignment Lock” to the intended new standard field LockType (subject to committee discussion and approval)

Regards,
Hanno.

Hanno,

Thank you so much for your response! it is indeed strange that you can’t modify the order despite being just a pre-allocation.

Based on your suggestions, I feel the following behavior could be a clean FIX implementation:

1. Two orders, one for buy 1000 @ market close and one for sell 500 @ market close are received
2. the buy & sell are matched and each party is informed that 500 shares are ‘pre-assigned’ to the other party. An ExecutionReport is sent with no price but ExecId=E1 and LockedQty[7770] and LockedInStatus[9487] to indicate that is a pre-assignment.
3. the buyer can only cancel now up to 500 shares. The seller cannot cancel anything.
4. At the end of the day, the pre-assignments turn into real matches and the buyer and seller get an execution report where ExecTransType[20]=Correction, the correct Price is sent and RefExecId=A1

This way a FIX compliant OMS could process the order correctly, even if it does not take in account the pre-allocation tags.

Warm regards

-C

[hanno.klein]

I am very, very cautious with new values for OrdStatus as this could severely impact existing applications. This translates to leaving OrdStatus = “New” with an additional field LockedQty having a non-zero value and showing that:

a) the order has not matched yet (in a regulatory sense)
b) part (or all) of the order quantity has been pre-assigned is (currently) not available for matching

This allows to model Carlos’ scenario but also many others where part or all of the order is temporarily not considered for matching or not accessible to the submitter. LockedQty is always equal to or less than LeavesQty. Orders could be locked and released and partially match multiple times during the trading day. In the more general case, OrdStatus could hence also be “Partially Filled” when locking occurs but would not change to this status due to locking.

Hanno,

What order status would you reccomend for a “pre-assignment locked” fill ? Would we need a new order status or would OrderStatus=PartiallyFilled / Filled suffice for this because at market close these preassigned / locked orders would anyway be partfilled / filled ?

Regards,
K. Mahesh

Carlos,

sounds good, a few more comments and issues to consider:

• You did not say which ExecType value you would want to use. You would need to send a price if sent as a fill (FIX 4.2 ExecType 1 or 2). Maybe it is better to send it as a restatement (ExecType D) and populate the lock fields to indicate the pre-assignment. The lock fields can be removed again at the end of the day when confirming the trade (unless you have multiple pre-assignments, i.e. your locked qty only gets reduced until it is finally zero)
• Apart from the technical issue (price needed for ExecType conveying a fill), there might be a business reason to not send a trade until it is actually done at the end of the day. What if the market is halted for some reason and “on close” orders are removed?
• Filled orders are considered to be in a terminal state (at least by exchanges) and fall out of the pool of active orders. You might not be able to inquire the order anymore (in your case the sell order for 500). Keeping the order state “New” avoids this problem.
• Modifications of “on close” orders (if permitted) need to take the locked qty into account and be rejected if the new qty falls below the locked qty (in your example, changing 1000 to less than 500)
• If you DO send out the pre-assignment as a trade: you described FIX 4.2 where ExecTransType is still valid. As of FIX 4.3 this field is deprecated and it would be just ExecType = G = Trade Correct instead.
• I will add another value “Pre-Assignment Lock” to the intended new standard field LockType (subject to committee discussion and approval)

Regards,
Hanno.

Hanno,

Thank you so much for your response! it is indeed strange that you can’t modify the order despite being just a pre-allocation.

Based on your suggestions, I feel the following behavior could be a clean FIX implementation:

1. Two orders, one for buy 1000 @ market close and one for sell 500 @ market close are received
2. the buy & sell are matched and each party is informed that 500 shares are ‘pre-assigned’ to the other party. An ExecutionReport is sent with no price but ExecId=E1 and LockedQty[7770] and LockedInStatus[9487] to indicate that is a pre-assignment.
3. the buyer can only cancel now up to 500 shares. The seller cannot cancel anything.
4. At the end of the day, the pre-assignments turn into real matches and the buyer and seller get an execution report where ExecTransType[20]=Correction, the correct Price is sent and RefExecId=A1

This way a FIX compliant OMS could process the order correctly, even if it does not take in account the pre-allocation tags.

Warm regards

-C

[kaymahes_x]

Hanno,

Why is Locked Qty always equals or less than leaves qty ?

Lets take the case of an market on close Order with OrderQty=1000 reaching a pre-assigning engine where it gets matched for LockedQty=600, then LeavesQty = 1000 - 600 = 400

Am I correct ?

Regards,
K. Mahesh

This allows to model Carlos’ scenario but also many others where part or all of the order is temporarily not considered for matching or not accessible to the submitter. LockedQty is always equal to or less than LeavesQty. Orders could be locked and released and partially match multiple times during the trading day. In the more general case, OrdStatus could hence also be “Partially Filled” when locking occurs but would not change to this status due to locking.

[hanno.klein]

This discussion is somewhat premature and should happen in the context of the public review of a proposal which has been preliminarily approved by the GTC. It has not even been discussed in a committee or working group that eventually submits it to the GTC.

That said, I will still answer your question.

The whole point is that the trade is NOT executed, i.e. OrdStatus is till “New” and LeavesQty is still 1000. Part of that 1000 has been locked due to “pre-assignment” and the recipient of the order will make sure that the locked qty continues to be available until the end of the day.

Compare it to a credit card transaction where you book into a hotel and they pre-assign the expected amount (or more) with the help of your creidt card company. The actual booking will not occur until you check out but the hotel can be sure to get the money when you check out and not run into a “credit limit exceeded” error because you bought a Porsche in the meantime

To conclude, please wait for (or join) the discussion in the GExMC and GTC to see if the concept has merit and how it will look if approved.

Thanks,
Hanno.

Hanno,

Why is Locked Qty always equals or less than leaves qty ?

Lets take the case of an market on close Order with OrderQty=1000 reaching a pre-assigning engine where it gets matched for LockedQty=600, then LeavesQty = 1000 - 600 = 400

Am I correct ?

Regards,
K. Mahesh

This allows to model Carlos’ scenario but also many others where part or all of the order is temporarily not considered for matching or not accessible to the submitter. LockedQty is always equal to or less than LeavesQty. Orders could be locked and released and partially match multiple times during the trading day. In the more general case, OrdStatus could hence also be “Partially Filled” when locking occurs but would not change to this status due to locking.

[kaymahes_x]

Thanks Hanno.

Taking the credit card example further, a customer is checking into a hotel using a credit card which has

credit limit = 1000 dollars

Total unpaid balance = 100 dollars

Hotel room rent = 100 dollars per day
Hotel Booking period = 3 days
Additional security deposit for any breakages / damages = 200 dollars

Hence amount of money for which Hotel will ask bank to put a lock = 100*3 + 200 = 500 dollars

So the available balance after this lock is placed is = 1000 - (100 + 500) = 400 dollars. Now customer cannot spend more than 400 dollars and the hotel is protected. The 500 dollars is locked until checkout. At checkout 300 dollars (3 days rent @ 100 dollars per day) would be charged. After room services reports to front desk it has verified that the room was left as expected with no damages / material removed, the lock on the other 200 dollars of security deposit is removed and becomes available for use.

Leaves Qty on an execution report should indicate the portion of the quantity that the order submitter still has control of, ie the quantity that can be cancelled.

I shall try to join the next GExMC / GTC discussion.

Regards,
K. Mahesh

This discussion is somewhat premature and should happen in the context of the public review of a proposal which has been preliminarily approved by the GTC. It has not even been discussed in a committee or working group that eventually submits it to the GTC.

That said, I will still answer your question.

The whole point is that the trade is NOT executed, i.e. OrdStatus is till “New” and LeavesQty is still 1000. Part of that 1000 has been locked due to “pre-assignment” and the recipient of the order will make sure that the locked qty continues to be available until the end of the day.

Compare it to a credit card transaction where you book into a hotel and they pre-assign the expected amount (or more) with the help of your creidt card company. The actual booking will not occur until you check out but the hotel can be sure to get the money when you check out and not run into a “credit limit exceeded” error because you bought a Porsche in the meantime

To conclude, please wait for (or join) the discussion in the GExMC and GTC to see if the concept has merit and how it will look if approved.

Thanks,
Hanno.

Hanno,

Why is Locked Qty always equals or less than leaves qty ?

Lets take the case of an market on close Order with OrderQty=1000 reaching a pre-assigning engine where it gets matched for LockedQty=600, then LeavesQty = 1000 - 600 = 400

Am I correct ?

Regards,
K. Mahesh

This allows to model Carlos’ scenario but also many others where part or all of the order is temporarily not considered for matching or not accessible to the submitter. LockedQty is always equal to or less than LeavesQty. Orders could be locked and released and partially match multiple times during the trading day. In the more general case, OrdStatus could hence also be “Partially Filled” when locking occurs but would not change to this status due to locking.

[kaymahes_x]

Hanno,

Pre-assignment of matched market close orders may need a new order status instead of order status=New because they have been pre-assigned and so in a sense are future executed, its neither New in terms of being fully cancelable nor is it Part-Filled or Filled because that “will” occur in the future. So the order submitter cannot cancel the pre-assigned locked quantity but has the freedom to cancel the unlocked quantity.

OrdStatus=Partially-filled / Filled cannot be used because the order is still not actually executed. Also when partially-filled / filled is used, price is required and market close price is not known before the market has actually closed.

Using OrdStatus=New and LockedQty>0 to mean pre-assignment could work, but a cleaner solution I see is an introduction of a new order status and corresponding order state change matrices.

Assuming a new order status enum is assigned for preassigned, in ExecReports when OrdStatus=Pre-assigned LastQty would become required and LastPx would become optional.

Also I recommend that when OrdStatus=Pre-Assigned, ExecType 150=I Order Status & ExecTransType=0 New be used. And have LeavesQty = OrderQty - CumQty so that order submitter knows what quantity can be cancelled.

Regards,
K. Mahesh

I am very, very cautious with new values for OrdStatus as this could severely impact existing applications. This translates to leaving OrdStatus = “New” with an additional field LockedQty having a non-zero value and showing that:

a) the order has not matched yet (in a regulatory sense)
b) part (or all) of the order quantity has been pre-assigned is (currently) not available for matching

This allows to model Carlos’ scenario but also many others where part or all of the order is temporarily not considered for matching or not accessible to the submitter. LockedQty is always equal to or less than LeavesQty. Orders could be locked and released and partially match multiple times during the trading day. In the more general case, OrdStatus could hence also be “Partially Filled” when locking occurs but would not change to this status due to locking.

Hanno,

What order status would you reccomend for a “pre-assignment locked” fill ? Would we need a new order status or would OrderStatus=PartiallyFilled / Filled suffice for this because at market close these preassigned / locked orders would anyway be partfilled / filled ?

Regards,
K. Mahesh

Carlos,

sounds good, a few more comments and issues to consider:

• You did not say which ExecType value you would want to use. You would need to send a price if sent as a fill (FIX 4.2 ExecType 1 or 2). Maybe it is better to send it as a restatement (ExecType D) and populate the lock fields to indicate the pre-assignment. The lock fields can be removed again at the end of the day when confirming the trade (unless you have multiple pre-assignments, i.e. your locked qty only gets reduced until it is finally zero)
• Apart from the technical issue (price needed for ExecType conveying a fill), there might be a business reason to not send a trade until it is actually done at the end of the day. What if the market is halted for some reason and “on close” orders are removed?
• Filled orders are considered to be in a terminal state (at least by exchanges) and fall out of the pool of active orders. You might not be able to inquire the order anymore (in your case the sell order for 500). Keeping the order state “New” avoids this problem.
• Modifications of “on close” orders (if permitted) need to take the locked qty into account and be rejected if the new qty falls below the locked qty (in your example, changing 1000 to less than 500)
• If you DO send out the pre-assignment as a trade: you described FIX 4.2 where ExecTransType is still valid. As of FIX 4.3 this field is deprecated and it would be just ExecType = G = Trade Correct instead.
• I will add another value “Pre-Assignment Lock” to the intended new standard field LockType (subject to committee discussion and approval)

Regards,
Hanno.

Hanno,

Thank you so much for your response! it is indeed strange that you can’t modify the order despite being just a pre-allocation.

Based on your suggestions, I feel the following behavior could be a clean FIX implementation:

1. Two orders, one for buy 1000 @ market close and one for sell 500 @ market close are received
2. the buy & sell are matched and each party is informed that 500 shares are ‘pre-assigned’ to the other party. An ExecutionReport is sent with no price but ExecId=E1 and LockedQty[7770] and LockedInStatus[9487] to indicate that is a pre-assignment.
3. the buyer can only cancel now up to 500 shares. The seller cannot cancel anything.
4. At the end of the day, the pre-assignments turn into real matches and the buyer and seller get an execution report where ExecTransType[20]=Correction, the correct Price is sent and RefExecId=A1

This way a FIX compliant OMS could process the order correctly, even if it does not take in account the pre-allocation tags.

Warm regards

-C

[carloshernandez18_x]

Hanno,

Thanks again, this discussion has been extremely fruitful. For the sake of completeness, here is how I plan the scenario would go:

1. A sends a buy x 1000 @ Market on Close order A1
2. A receives an ExecutionReport ExecType[150]=0-New
3. B sends a sell x 500 @ Market on Close order B1
4. B receives an ExecutionReport ExecType[150]=0-New
5. The exchange matches A1 and B1 by pre-allocating them and sends the corresponding ExecutionReport with:
   ExecType[150]=D-Restated
   ExecRestatementReason[378]=“Pre-allocation”
   LockedQty[7770]=500
   LockedInStatus[9487]= “Pre-Assignment Lock” (subject to review)
   and all other fields stay the same. As result the order remains on the New state, and does not confuse OMS even if they don’t want to deal with the pre-allocation process.

Once the actual matching with a given price happens, everything else can be done according to standard.

Thanks again for your help and have a great weekend.

-C

Carlos,

sounds good, a few more comments and issues to consider:

• You did not say which ExecType value you would want to use. You would need to send a price if sent as a fill (FIX 4.2 ExecType 1 or 2). Maybe it is better to send it as a restatement (ExecType D) and populate the lock fields to indicate the pre-assignment. The lock fields can be removed again at the end of the day when confirming the trade (unless you have multiple pre-assignments, i.e. your locked qty only gets reduced until it is finally zero)
• Apart from the technical issue (price needed for ExecType conveying a fill), there might be a business reason to not send a trade until it is actually done at the end of the day. What if the market is halted for some reason and “on close” orders are removed?
• Filled orders are considered to be in a terminal state (at least by exchanges) and fall out of the pool of active orders. You might not be able to inquire the order anymore (in your case the sell order for 500). Keeping the order state “New” avoids this problem.
• Modifications of “on close” orders (if permitted) need to take the locked qty into account and be rejected if the new qty falls below the locked qty (in your example, changing 1000 to less than 500)
• If you DO send out the pre-assignment as a trade: you described FIX 4.2 where ExecTransType is still valid. As of FIX 4.3 this field is deprecated and it would be just ExecType = G = Trade Correct instead.
• I will add another value “Pre-Assignment Lock” to the intended new standard field LockType (subject to committee discussion and approval)

Regards,
Hanno.

Hanno,

Thank you so much for your response! it is indeed strange that you can’t modify the order despite being just a pre-allocation.

Based on your suggestions, I feel the following behavior could be a clean FIX implementation:

1. Two orders, one for buy 1000 @ market close and one for sell 500 @ market close are received
2. the buy & sell are matched and each party is informed that 500 shares are ‘pre-assigned’ to the other party. An ExecutionReport is sent with no price but ExecId=E1 and LockedQty[7770] and LockedInStatus[9487] to indicate that is a pre-assignment.
3. the buyer can only cancel now up to 500 shares. The seller cannot cancel anything.
4. At the end of the day, the pre-assignments turn into real matches and the buyer and seller get an execution report where ExecTransType[20]=Correction, the correct Price is sent and RefExecId=A1

This way a FIX compliant OMS could process the order correctly, even if it does not take in account the pre-allocation tags.

Warm regards

-C