DMA implementation

, ,
1

Imported from previous forum

2

Hi

We are looking to offer DMA connectivity to our clients. We are in the process of analysing the requirements - from IT point of view and trying to outline our project task. based on some initial analysis i am listing the details. I will appreciate if anyone with DMA implementation experience can provide some suggestions as they have experienced during their implementation.

1.We will have seperate FIX session for DMA order flow from client.
2. We will route the order to the exchange directly - or through a third party in case we cannot route the order directly to the exchange.
3. All message routed to exchange/3rd party - will be recorded in our OMS for monitoring purpose only. In case of an event where the client connection is down - and orders need to be cancelled on the exchange we will have the capability to cancel open orders from the OMS to the exchange.
4. We will also receive FIX drop copies of executions and may be the order messages, so we can book the trades into our Middle office system

Questions

  1. In the situation where we need to manually cancel the open orders in the exchange - will it be sufficient to only have the information of OrderID - since if we are not directly routing the order to the exchange, then we do not know what was the final ClOrdID created when the order reached the exchange. Has anyone encountered this situation. How have you managed to get the information on the final ClOrdID that the exchange knows - in what situation will this be required.

  2. If you do not have a direct FIX session with the exchange - how do you track that the order that you routed has actually reached the exchange. - I am thinking that we have the option where we can set the time limit on which we need to receive an Ack back on the DMA order - will this be sufficient. If we do not receive the ack in an acceptable time range - then we may decide to issue cancel on those orders. What is the norm in this situation

3.Has anyone seen the need to provide FIX drop copies to DMA clients along with the real time executions?

  1. Does any client request an end of day replay of all FIX messages ?

  2. How did you test exchange connectivity while the project was ongoing - without actually testing with the exchang. Is there any open source for an exchange simulator.

Any other suggestion are appreciated.

Regards

3

On your first question about order identification: If your third party indeed issues its own ClOrdIDs when communication with the exchange, they should use SecondaryClOrdID to communicate these to you. You can then use this field in the OrderCancelRequest to identify the order at the exchange. Question is why you really need to know them if you do not interact directly with the exchange.

You say “we do not know what was the final ClOrdID created when the order reached the exchange”. Just to be clear, the exchange does not create ClOrdID when the order arrives, it will create OrderID. Your third party might create their own ClOrdID/OrderID values.

Why can’t the third party simply route your orders through and send you the responses? If they aggregate orders from multiple clients like you and then send just a single order to the exchange, you do not have a 1:1 relationship between your transactions and those going to/coming from the exchange. Then you only have your own ClOrdID and the OrderID issued by the third party. Why should you need exchange IDs if you do not communicate directly? Your third party has to map your IDs to the ones he has created towards the exchange.

Regards,
Hanno.

Hi

We are looking to offer DMA connectivity to our clients. We are in the
process of analysing the requirements - from IT point of view and trying
to outline our project task. based on some initial analysis i am listing
the details. I will appreciate if anyone with DMA implementation
experience can provide some suggestions as they have experienced during
their implementation.

1.We will have seperate FIX session for DMA order flow from client.
2. We will route the order to the exchange directly - or through a third
party in case we cannot route the order directly to the exchange.
3. All message routed to exchange/3rd party - will be recorded in our
OMS for monitoring purpose only. In case of an event where the
client connection is down - and orders need to be cancelled on the
exchange we will have the capability to cancel open orders from the
OMS to the exchange.
4. We will also receive FIX drop copies of executions and may be
the order messages, so we can book the trades into our Middle
office system

Questions
5. In the situation where we need to manually cancel the open orders
in the exchange - will it be sufficient to only have the
information of OrderID - since if we are not directly routing the
order to the exchange, then we do not know what was the final
ClOrdID created when the order reached the exchange. Has anyone
encountered this situation. How have you managed to get the
information on the final ClOrdID that the exchange knows - in what
situation will this be required.

  1. If you do not have a direct FIX session with the exchange - how do
    you track that the order that you routed has actually reached the
    exchange. - I am thinking that we have the option where we can set
    the time limit on which we need to receive an Ack back on the DMA
    order - will this be sufficient. If we do not receive the ack in an
    acceptable time range - then we may decide to issue cancel on those
    orders. What is the norm in this situation

7.Has anyone seen the need to provide FIX drop copies to DMA clients
along with the real time executions?

  1. Does any client request an end of day replay of all FIX messages ?

  2. How did you test exchange connectivity while the project was ongoing

    • without actually testing with the exchang. Is there any open source
      for an exchange simulator.

Any other suggestion are appreciated.

Regards

4

Hi

Thanks for the feedback.
Mohamed your input to use custom tags as agreed with the 3rd party will help us to track the final ClOrdID that was create by the 3rd party before routing to the exchange.
In most cases as i understand we will always have to do a automatic cancel of the order - for this we will always refer to our ClOrdID so there will be no need of knowing the ClOrdID that the 3rd party submitted to the exchange.
Hanno - thanks for providing more info that it is quite likely that the 3rd party may combine several orders before they submit it to the exchange. So in that case knowing the ClOrdID that was sent to the exchange is going to be of no use.

On your first question about order identification: If your third party
indeed issues its own ClOrdIDs when communication with the exchange,
they should use SecondaryClOrdID to communicate these to you. You can
then use this field in the OrderCancelRequest to identify the order at
the exchange. Question is why you really need to know them if you do not
interact directly with the exchange.

You say “we do not know what was the final ClOrdID created when the
order reached the exchange”. Just to be clear, the exchange does not
create ClOrdID when the order arrives, it will create OrderID. Your
third party might create their own ClOrdID/OrderID values.

Why can’t the third party simply route your orders through and send you
the responses? If they aggregate orders from multiple clients like you
and then send just a single order to the exchange, you do not have a 1:1
relationship between your transactions and those going to/coming from
the exchange. Then you only have your own ClOrdID and the OrderID issued
by the third party. Why should you need exchange IDs if you do not
communicate directly? Your third party has to map your IDs to the ones
he has created towards the exchange.

Regards, Hanno.

Hi

We are looking to offer DMA connectivity to our clients. We are in the
process of analysing the requirements - from IT point of view and
trying to outline our project task. based on some initial analysis i
am listing the details. I will appreciate if anyone with DMA
implementation experience can provide some suggestions as they have
experienced during their implementation.

1.We will have seperate FIX session for DMA order flow from client.
2. We will route the order to the exchange directly - or through a
third party in case we cannot route the order directly to the
exchange.
3. All message routed to exchange/3rd party - will be recorded in our
OMS for monitoring purpose only. In case of an event where the
client connection is down - and orders need to be cancelled on the
exchange we will have the capability to cancel open orders from the
OMS to the exchange.
4. We will also receive FIX drop copies of executions and may be the
order messages, so we can book the trades into our Middle office
system

Questions
5. In the situation where we need to manually cancel the open orders
in the exchange - will it be sufficient to only have the
information of OrderID - since if we are not directly routing the
order to the exchange, then we do not know what was the final
ClOrdID created when the order reached the exchange. Has anyone
encountered this situation. How have you managed to get the
information on the final ClOrdID that the exchange knows - in what
situation will this be required.

  1. If you do not have a direct FIX session with the exchange - how do
    you track that the order that you routed has actually reached the
    exchange. - I am thinking that we have the option where we can set
    the time limit on which we need to receive an Ack back on the DMA
    order - will this be sufficient. If we do not receive the ack in an
    acceptable time range - then we may decide to issue cancel on those
    orders. What is the norm in this situation

7.Has anyone seen the need to provide FIX drop copies to DMA clients
along with the real time executions?

  1. Does any client request an end of day replay of all FIX messages ?

  2. How did you test exchange connectivity while the project was
    ongoing

    • without actually testing with the exchang. Is there any open
      source for an exchange simulator.

Any other suggestion are appreciated.

Regards

5

Example Scenario:

Request:

Client to DMA System --> 35=D, 11=ABC, … (ABC is the unique ID in client system)

DMA System to 3rd Party --> 35=D, 11=DEF, 526=ABC, … (DEF is unique ID in DMA System for this order)

3rd Party to Exchange --> 35=D, 11=GHI, 526=DEF, … (GHI is the unique ID in 3rd Party System)

Response:

Exchange to 3rd Party --> 35=8, 11=GHI, 526=DEF, 37=JKL (JKL is the order ID in Exchange)

3rd Party to DMA System --> 35=8, 11=DEF, 526=ABC, 37=GHI, 198=JKL

DMA System to 3rd Party --> 35=8, 11=ABC, 37=DEF, 198=GHI

198 and 526 are optional tags and not necessary to be available by default. If you will need these info, that should be agreed with all parties involved. Each of the system that routes orders to other venues will need to creat unique ID in the system to handle multiple different client orders in their OMS.

If the order is routed to 3rd party, the cancellation request will be sent to 3rd Party only. That will trigger a cancellation request from 3rd Party to Exchange and cancel the order in exchange.

However, if you have the option to override the 3rd party in extreme events and call up Exchange directly to cancel the orders over phone, then you will require Exchange ID / 3rd Party clordid.

Exchange will be able to pull up the order in their books based on any one of these two ID. Your system will have this from the information available in 37 Tag of the responses sent by 3rd Party.

Time limit on No Ack Order:

3rd Party can issue a pending Ack immediately on receipt of the order and send New once it is confirmed in Exchange.

You can plan to cancel or trigger a status request that will warrant a response from 3rd Party to give the status of the order.

How to track the order is successfully delivered to Exchange by the 3rd Party?

Agree with 3rd Party to provide 198 tag with Exchange order id in the responses which will help you resolve this.

End of Day Replay will be costly if the transactions volume are very high. Unless the client system is in full recovery mode, such need will not arise.

You can use commercially available test tools from various organizations that mimic each of the exchanges. Also, you can build your own simulators using open source like quickfix.

Hope this helps