Hi,
We receive ERs from a system where we were not involved in the full quoting lifecycle. So the 1st interaction is to receive an ER.
It’s a mechanism for us to receive a notification of an FX trade (all spot for now) where we send to another system for hedging etc. We now need to differentiate the ER’s based on how the trade was priced (only known to the source system) that want to send this value to indicate GOLD, SILVER, BRONZE price type.
I don’t want to create a custom fix tag in our dictionary unless absolutely necessary. I took a look at the ER msg but cannot find anything appropriate so seeking advice.
Can you provide some more context here? I understand the incoming side of the ER were you receive an actual trade with the price at which it was traded. I am less clear about the ongoing side and the second data element which I believe you call “price type” and “how the trade was priced”. Can you provide examples for values of this? You intend to forward the incoming ER as another ER with additional information, correct?
This is a flow where we do not quote the price for these FX trades, merely accept the ER. It would have been priced by the sender & they are using us to send this trade to another component via an ER msg. So we have no information on the client or their pricing (stream assigned to them) as this is done by the sender. We implemented the usage of ER for them to send us this trade notification.
They currently send Account (Tag 1) to represent the client, Price (Tag 44) as the price it was executed. We do not maintain the client or the price stream, this is all external to us.
Now they want us to route it differently downstream depending on the price stream that was used when client was priced (call it GOLD vs SILVER etc.).
Looking for a fix tag within the ER that will allow them to send this value “GOLD” etc. as another parameter of the trade notification. I am trying to avoid a custom tag unless I have to.
Price(44) in the ExecutionReport(35=8) does not contain the price at which an order was executed. It is the price at which a limit order was submitted to the market. LastPx(31) is the correct tag to use for this.
I now understand that you are looking for a tag that “they” can send to you to allow you to make a distinction of price streams. A simple solution (based on your example) is to use ProductComplex(1227) with the strings “GOLD” or “SILVER” as values. Another option is SecurityGroup(1151). You can choose the names as you wish in both cases. Just make sure you are not using these tags for other groupings.
Interesting note on 44 vs 31, I think we are using 44 on the standard flow where we price and send an ER back in response to the NewOrderSingle with the executed price in 44, as we are processing market orders.
Re: the stream value, the tags you mentioned are close but are but are potentials maybe.
thank you for pointing me there, i will take a look to see if it is fit for purpose as I need to make the call on using a tag that is meant for something else vs creating a custom tag
Was looking at the StreamGrp component in the ER, that has 41303 as the StreamID but unsure of the intention for this group/tag and if it is correct to use it to indicate a type of FX price category (gold, silver)
@indigostar108 StreamGrp is NOT to be used for what you’re trying to achieve. That component is about swaps.
I understand what you’re doing. Thru a price feed aggregator a bank may assign tell the aggregator that they want the bank’s clients to be assigned to the GOLD price tier feed vs. SILVER price tier feed, etc. FIX has the StreamAssignment messages for the assignment part which you may already know about. Now you want to be able to identify in the ER which price tier the ER resulted from, right?
If my understanding of your requirement is correct I would suggest that you add the MDStreamID(1500) to the ER message. This field is specifically used to identify price stream a client was assigned to.
Right now MDSTreamID is not part of the ER whatsoever which is why I suggest you enhance your ER msg with that field. You’re trying to identify which stream the client was assigned to that resulted in the pricing used for the ER right? If that is true then I don’t see any reason why you shouldn’t add MDStreamID to your ER.
If you had used StreamXID(41303) your hand would get slapped Note that that field is not called “StreamID”, there is an “X” in there and it’s a technical use for cross referencing within the same message.
Note that that field is not called “StreamID”, there is an “X” in there and it’s a technical use for cross referencing within the same message.