Xetra EnLight is a service that allows brokers to send directed quote requests to dealers via Xetra’s T7 platform. Dealers send quotes and the broker can choose to hit/lift the quote. Moreover, the brokers can cancel or update the RFQ when their intentions have changed.
EnLight AutoExecution is a feature of the service which allows the broker to have their RFQ automatically executed without the need to manually hit/lift the quote. The broker would send a directed RFQ with some extra information (price criterion, quote collection duration, min number of quotes, settlement information). When the criteria is met, the RFQ is either executed (resulting in a trade) or eliminated. This means that an AutoExecution RFQ behaves more like a new order request than a private RFQ.
The problem is that suppose a client sent an AutoExecution RFQ to Xetra but no longer wants to be executed, they have no means to withdraw because the FIX protocol does not allow quote requests to be canceled or updated.
Proposed Solution
Single Order Workflow
One solution is to use the single order workflow to map to EnLight AutoExecution. FIX Clients will use 35=D, 35=F and 35=G to submit, cancel and replace the Quote Requests.
The following diagram shows the interaction between the FIXBroker and Xetra.
The drawback of this solution is that FIX Brokers would send new order requests to use the AutoExecution service, while for the regular EnLight they would use RFQ.
RFQ Workflow + Cancel/Replace Requests
Another solution is to use the RFQ workflow and for the cancel/update we could use 35=F and 35=G.
The drawback of this is that it is not standard to “cancel/replace” an order which was never placed, although conceptually, the RFQ can be seen as an order.
Question
What are the other alternatives FIX protocol provides to cancel or update a Request for Quote that allow for a better standardization?
If you even use the regular Order workflow to cancel or update QuoteRequests, why not use Quote and QuoteCancel instead?
Alternatively, couldn’t you send a QuoteRequest again but e.g. with an empty price/quantitiy or an updated ExpireTime to indicate that it is no longer valid?
The rationale behind using Cancel/Replace to cancel/update the QuoteRequests is that for the regular flow, the FIXBroker would get a Quote and will place a New Order Single to hit/lift the quote. However, you are right that we could send Quote instead of QuoteRequest and QuoteCancel instead of RFQCancel. The question is, what would be the advantage of using quotes over using orders?
That was another idea, but is it standard to send another RFQ message to update/cancel a quote request? This would imply sending a new RFQ message but having the same QuoteReqID. I think our clients might be confused.
I just was thinking because it feels more “natural” since you are dealing with quotes. But in the end it probably doesn’t matter.
Hmm, maybe misuse ClOrdID or RFQReqID to correlate the quotes?
But on the other hand: isn’t the quote meant for a specific instrument/security/symbol? Shouldn’t a quote for the same replace the earlier quote? So it wouldn’t matter if you send a new ID or not.
In implementations I have been involved with in the fixed income world, when the client has a need to cancel a previously sent QuoteRequest(35=R) we use the QuoteResponse(35-AJ) with QuoteRespType(694)=6 (Pass). Client “passing” is common in FI RFQ models and it serves as an end state.
So where you have the [cancel RFQ] in your second flow diagram use the QuoteResponse(35=AJ) with QuoteRespType(694)=6 (Pass).
I would not advise this. Quote(35=S) should only be sent by the party issuing the quote. In this scenario the FIXBroker is sending an RFQ (i.e. I want a bid/ask for this stock) to Xetra, not a Quote.
Well, I need to object to a suggestion to misuse standard fields, especially when it is about key identifier fields I think @ltaikit provided the best option to deal with this situation. In terms of when to issue a new ID, keep in mind that FIX distinguishes between a message identifier and an entity identifier. QuoteReqID(131) is a message ID whereas QuoteID(117) is an entity ID. I know that the FIX design was not always clear on this in the early days. QuoteMsgID(116) was not introduced until after FIX 4.4 to offer a message ID for quotes.
Last comment on this is that there are trading models that support more than one quote per instrument. A new quote hence does not necessarily replace the existing one and then needs its own ID.
@christophjohn please do not let yourself be intimidated by @ltaikit or me responding! Thank you for your continued contributions and I can only encourage others to come forward to ask questions or respond to questions. That is the only way we can identify true gaps in the FIX Protocol.
QuoteResponse with QuoteRespType=6(pass) looks like a good candidate to cancel the RFQ. Although QuoteResponse would typically be used as a reply to a Quote, reading through the Pre Trade FIX specification it seems it can also be used to “end a negotiation”.
When it comes to replacing the initial RFQ, am I right to assume that we could use the same QuoteResponse with QuoteRespType=2(counter) to update it? Is there a better alternative?
This is an interesting one because in the implementations I’ve been involved in we hadn’t had to do this in the way you describe . It’s been done as a “cancel” and “new” as opposed to “amend” paradigm. Cleaner for the FI markets I deal with.
If you must do an “amend” I’m a bit leery about using “counter” here as you’re not countering a Quote. This maybe worth a gap analysis to do this properly.
FIX does not provide a transactional field XXXTransType for the QuoteRequest(35=R) message. It does provide a repeating group to request quotes for multiple instruments in a single request. The QuoteResponse(35=AJ) with QuoteRespType(694)=6 (Pass) can be used to terminate the request for a single instrument.
I would argue that a modification semantic should not be supported beyond sending another QuoteRequest(35=R) message with a new QuoteReqID(131) and modified attributes. The new RFQ can have a single instrument in the repeating group. The recipient can recognise that the RFQ is for an instrument for which there is already an active RFQ and make a replacement. It is an implicit replacement. The quote can then refer to the new QuoteReqID(131) to indicate that it follows the modified attributes.
Understood.
To wrap up, I will use the QuoteResponse (AJ) message with QuoteRespType(694)=6(pass) to cancel the RFQ. To “modify” an RFQ, we will cancel the initial one and resubmit it with modified attributes.
Sorry for stepping in here since I probably missed one point in the thread.
Work flow is fine before trade/AE is sent to client.
What happens if:
We observe trade execution and cxl request messages crossing?
Would that mean that
a.) the trade execution has to be accepted by client anyways and the cxl request is then rejected (“too late”) by sell side at this stage of transaction status or is
b.) the cxl request accepted anyways and the trade is cxld with ER 150=H by sell side? Hoping and assuming no connectivity interruption taking place during this critical period.
Apologies if not relevant at all - but still curious what business transaction flow EnLite will implement and what message flow is going to reflect it:slight_smile:
@111s, suppose the client sent the cancel request to Xetra but the Trade is on the wire from Xetra to the client, my understanding is that the cancel request would be rejected by Xetra with a “too late to cancel” kind of error code.
I think 
. It’s been done as a “cancel” and “new” as opposed to “amend” paradigm. Cleaner for the FI markets I deal with.