I have a FIX server which supports open/close positions. Now, I want to add support for pending orders.
In the NewOrderSingle message, there is a field OrdType which defines the type of order, Market,Limit,Stop, etc. I used these ones for position orders. Now I need a parameter for pendings..
I considered adding another parameter to the NewOrderSingle message but wonder if there's a better way..?
I think you are looking at the wrong message type. ExecutionReport has an OrdStatus field that you can set to "pending new".
NewOrderSingle is for a trader to submit an order, and that's all. A trader wouldn't mark his own order as "pending" when he submits it! The server responds to the trader with an ExecutionReport that has the appropriate OrdStatus.
Apologies if I'm telling you things you already know. There's not a lot of context in your question.
Related
I'm attempting to implement a FIX protocol in .NET with QuickFIX in order to automatically send out trade orders. Sending orders with the OrderQty tag doesn't raise any issues, however when using the CashOrderQty tag, the host returns the error message "Conditionally Required Field Missing". The message already includes all the specified fields required for CashOrderQty, the error only disappears if I add OrderQty to the message, however the documentation explicitly states only one of the two must be sent in the message.
I would agree with the earlier comments - it seems to be a question to your counter-party, no issue with QuickFix/n as such. It (apparently) correctly delivers the trade order message to the exchange, and the exchange's response back to you, so only the maintainer of the exchange's documentation could explain the reasons for the behavior your see.
Check FIX.xml dictionary on your side, it should match the third party documentation in terms of required and optional fields + supported fields.
I have a question regarding FIX Protocol and I'm quite new to it.
A client sent an order and it got accepted by the broker. After that, the client sent a request (request #1) to modify the quantity to x. However, before request #1 is accepted, the client sent another modification request (request #2) to modify the quantity to y.
I search the documentation of FIX Protocol and find these.
The order sender should chain client order ids on an ‘optimistic' basis, i.e. set the OrigClOrdID <41> to the last non rejected ClOrdID <11> sent
The order receiver should chain client order ids on a ‘pessimistic' basis, i.e. set the OrigClOrdID <41> on execution reports that convey the receipt or succesful application of a cancel/replace and Order Cancel Reject <9> messages to be the last ‘accepted' ClOrdID <11> (See "Order State Change Matrices" for examples of this)
However, I still don't understand how FIX Protocol handles request. Will the quantity be modified to y? Or does it depend on which request is being accepted last?
You need to understand that the FIX Protocol is a set of guidelines on how someone who implements the protocol should handle certain scenarios. In practice there are differences in how counterparties handle this.
In your example the quantity should be modified to y in the end. But the quantity will be modified to x first since that message was received at first.
Here are some chaining examples taken from the spec:
https://www.onixs.biz/fix-dictionary/4.4/app_d.html (search for sequencing or chaining)
Here are examples specific to your question where two consecutive replace requests are handled:
https://www.onixs.biz/fix-dictionary/4.4/app_dD.2.a.html
https://www.onixs.biz/fix-dictionary/4.4/app_dD.2.b.html
If you're in a microservice architecture where a business user needs admin capabilities to add and remove items from a database for that service and wants a message saying the operations were successful or not, so not just a 201 response.
When you are returning a response for a POST and DELETE what is the preferred industry practice? To send back a string message saying it was successful or not? Or would it be better to have a new value object with a member String message, and getter/setter returned, that can be serialized and returned into the response the user will see?
Is there a preferred approach, or does it not matter?
It depends.
The message-body of an HTTP response is, semantically, a message.
200 OK
Content-Type: text/plain
IT WORKED
Using plain text for messages is fine when the message recipient is a human, because humans are semantically flexible. A human familiar with American English is going to understand that message, and if you later decide to change it to a less shouty spelling, the human recipient will probably be able to work it out.
When machines are reading the message, plain text becomes less satisfactory -- the problem comes when you need to change the message, and without structure the machines have a difficult time finding what they need.
If you look at the example above, the headers, including the status-line, conform to a schema designed some 20 years ago. HTTP clients know how to parse the headers, and identify headers that they care about, and so on, because there is a well specified pattern to how information is encoded into the header of the response.
In the short term, you could define a schema where "IT WORKED" is one of the possible responses, and everybody could write their programs in accordance with that schema.
But when you need to extend the schema, to include more information? Can you satisfy your future requirements without breaking old clients?
On the other hand, if it is inexpensive to upgrade all of the clients (because they are all under your direct control?) then maybe you don't need an extensible message schema yet.
Could anyone point me to the relevant section of the FIX spec pertaining to rejected order modification?
Please consider the following scenario:
A limit order (NewOrderSingle: ClOrdID='blah.0') is placed and
confirmed as submitted by the broker
Modification request of the order (OrderCancelReplaceRequest:
ClOrdID='blah.1'; OrigClOrdID='blah.0') gets rejected due to, say,
limit violation
What happens to the original order (ClOrdID='blah.0')? Is it still considered valid and can be filled? Does the FIX specification define the expected behavior for such scenarios and the expected state of the original order?
TL;DR
You should consult your counterparty's FIX specification document(s) for the exact behavior to expect from that specific counterparty when an attempt to replace a working order is rejected.
Long answer
Assuming nothing has happened to the original order 11=blah.0 between the time it was placed and the OrderCancelReplaceRequest with 11=blah.1|41=blah.0 was sent and rejected (e.g., fill, partial fill(s), external cancel), the original order 11=blah.0 should still be working, and can be filled.
There is nothing in the FIX specification that states the exact expected outcome when an attempt to replace a working order is rejected. Since most exchanges/brokers use some flavor of FIX 4.2, I'll point to the documentation for that version:
Order Cancel Reject - The order cancel reject message is issued by the
broker upon receipt of a cancel request or cancel/replace request
message which cannot be honored. Requests to change price or decrease
quantity are executed only when an outstanding quantity exists. Filled
orders cannot be changed (i.e quantity reduced or price change.
However, the broker/sellside may support increasing the order quantity
on a currently filled order).
In the message specification it has:
Tag | Field Name | Req'd | Comments
39 | OrdStatus | Y | OrdStatus value after this cancel reject is applied.
Whatever the counterparty provides for OrdStatus in the OrderCancelReject message is the state of the original order. I have never run into any counterparty that cancels the original order when a replace request is rejected, but I suppose it's possible. If a counterparty does handle the situation this way, any documentation provided by the counterparty should clearly state so.
I'm pretty new to the FIX protocol and was hoping someone could help clarify some terms.
In particular could someone explain (perhaps with an example) the flow of NewOrderSingle, ExecutionReport, CancelReplaceRequest and how the fields ClOrdID, OrdID, OrigClOrdID are used within those messages?
A quick note about usages of fields. My experience is that many who implement FIX do it slightly differently. So be aware that though I am trying to explain correct usage you may find that there are differences between implementations. When I connect to a new broker I get a FIX specification which details exactly how they use the protocol. I have to be very careful to make sure where they have deviated from other implementations.
That said I will give you a rundown of what you have asked for.
There are more complicated orders but NewOrderSingle is the one most used. It allows you to create a trade for any asset. You will need to create a new order using this object / msg type. Then you will send it through your session using the method sendToTarget(). You can modify the message after this point through the toApp() method, assuming your application implements the quickfix.Application interface.
The broker (or whoever you are connected to) will send you a reply in the form of and Execution report. Using quickfix that reply will enter your application through the fromApp() callback. From there the best thing to do is to implement your app inheriting from the MessageCracker class (or implement it elsewhere) using the crack method from MessageCracker it will then call back a relevant onMessage() method call. You will need to implement a number of these onMessage() methods (it depends on specifically what you are doing as to which methods you will need), the main one being onMessage(ExecutionReport msg, SessionID session). This method will be called by message cracker when you receive and Execution report from the broker. This is the standard reply to a new order.
From there you handle the reply as required.
Some orders do not get filled immediately like Limit orders. They can be changed. For that you will need the CancelReplaceRequest. Your broker will give you details of how to do this specifically for them (again there are differences and not everyone does it the same). You will have to have done a NewOrderSingle first and then you will use this MsgType to update it.
ClOrdID is an ID that the client uses to identify the order. It is sent with the NewOrderSingle and returned in the ExecutionReport. The OrdID tag is in the ExecutionReport message, it is the ID that the broker will use to identify the order. OrgClOrdID is usually used to identify the original order in when you do and update (using CancelReplaceRequest), it is supposed to contain the ClOrdID of the original order. Some brokers want the original order only, others want the ClOrdID of the last update, so the first OrigClOrdID or will be the ClOrdID of the NewOrderSingle, then if there are subsequent updates to the same order then they will be the ClOrderID from the last CancelReplaceRequest. Some brokers want the last OrderID and not ClOrderID. Note that the CancelReplaceRequest will require a ClOrdID as well.