FIX as a pre-trade inhouse integration processing option

1

Dear all,

Currently customizing an OMS/EMS by an internal system integration project into a banks pre-order processing.

This includes

1 communication with the custodian system (and DMA router) to check whether an account owner holds sufficient instruments to sell a certain order quantity.
2 communication with a „best execution engine“ responding the policy-compliant venue on request. This component could also be chosen by the OMS as the DMA routing system for this order in a second step.

These systems in question have their proprietary interfaces and message flow. But they are already attached to a EAI mapping message broker and this is capable of understanding any FIX version and translating to/from the prop interfaces…

Our general idea now is to faciliate the communication on the OMS side regarding both use cases hopefully by the use of the FIX protocol. OMS is representing the buy side.

One approach to address both use case ist to send the-check requests seperately and consecutively.

Another approach to combine both use cases in one request may possibly be to send a NewOrderSingle with 18=k and the venue (tags 100 and 207) left blank. Best Execution Policy related flags and more information are transported via the StrategyParametersGrp of the order. Additionally 18=w (lock) prevents the targeted system from routing the order.

One could think of using ValuesCheckGrp starting with 1858 since this Group supports a quantity check. This quantity check would not investigate on current market situation (which is probably the original business related use case intention of the check) but it veryfies the free quantity available and sufficient on the owners account.

Or would it be a violation on the business case related to the DisclosureInstructionGrp starting 1868 if we would use even this one ? Since DisclosureType also contains quantity and value > 100 is even open to bilateral agreement.

An Execution Report returns tag(s) 100 and/or 207 populated with the venue fitting the order requestor‘s profile according to the „best execution policy“ and additionally a tag37 value in case of positive result for both requests.

In the negative response the order will be rejected 39=8. The easy one.

If both request results were positive and the values were returned to the OMS, which status 39= whould we chose ? Probably „A“=Pending New“ or „New“?

By sending a ReplaceRequest with tag 37 and venues MICs populated from the BestExecution Response and 18=q (Release) from the OMS could then instruct the DMA router to release the order to the market.

I am afraid this is not an industry standard bullet proof approach but it hopefully does not only generate roll-eyes …
We‘d be extremely happy if you share your comments and ideas.

Thank you and Kind Regards
Uli

2

Hi Uli,

many questions :smirk:, here are some answers (my personal view).

  • DisclosureInstructionGrp does not apply here. That is only to control what information from the order is to be seen by the market.
  • ValueChecksGrp is the right component to instruct the recipient to only accept the order if the volume is approved.
  • ExecInst(18) = w/q were both intended to be used on order modifications in the context of a market maker trying to get an active order filled somewhere else (routed out). I can see an extension of this concept to add an order without making it tradeable. Response to that should be an order status of “Pending New” as “New” confirms an accepted, immediately tradeable order.
  • Acceptance of execution venue information (ExDestination(100)) suggested by the recipient can be confirmed by an OrderCancelReplaceRequest from the submitter. Response to that would then be an order status of “New”, making the order tradeable. However, this flow is unusual as “Pending New” normally leads to “New” without the submitter having to send another message as would be the case in your flow.
  • You could use an ER with ExecType(150)=D (Restated) (and “Pending New” order status) to remind the submitter that you are still waiting for him to confirm the order. You may want to use an unsolicited cancel if you do not get a response within a certain time limit.
  • SecurityExchange(207) is only part of the instrument definition and not related to the actual execution venue.

Regards,
Hanno.

3

Hanno,

Herzlichen Dank for your response to “many questions” indeed. Very helpful indeed.

Such complex request-response game may probably point towards a wider use of FIX in integration sceanrios and a use case extension for instance such as “Requested Data Enrichment” to a dedicated service.

Here is one more out of many: An OMS sending a high Qty order to an Algo Wheel service which in return provides a TCA optimized list (NewOrderList 35=E) of split orders to work on.

If there is a some interest in the industry in extending FIX by adding a rather generic use of the request/response and subscribe protocol features it would be worth compiling and standardizing it while always lead by the GTC.

Anyway, after more than 20 year of working with FIX protocol now and am only 1 year away from retirement I don’t think I will see such a development unfold.

Kind regards und Thanks again.

Uli

4

Hi Uli,

before you enter into your well-deserved retirement, I hope you had or will have a chance to get engaged with the FIX Orchestra Technical Standard and the various FIX Orchestra tools (e.g. Log2Orchestra, Tablature) the GTC is making available to the community.

FIX Orchestra Technical Standard also includes the means to define scenarios, actors, flows and state machines so that you can create meta-data for your various use cases. The standard is extremely powerful for complex use cases and Tablature offers markdown as an easy authoring tool to describe them and subsequently convert to a standard Orchestra XML fie. The latter can then serve as an input to your development and testing environments. In case you already know all of that, I wrote it down for others that may not :slight_smile: .

Regards,
Hanno.