"Ghost operations" with low TF robots

• 07/06/2020 at 9:05 AM #138535
  GraHal

  Nicolas wrote:

  Let us know when you get any news from IG please.

  IG responded with below …

  From the capture you have sent us it seems that there is an error in how ProRealtime is showing you the ProOrder history.

  You have divided an operation (blue arrow in your screenshot) into two different ones (blue arrow + red arrow).

  That 0.92 contract operation on Dax € 1 was opened on 06/15 at 08:04 and closed at 11:52 on the same day with a loss of € 166.43, which as you can see is the sum of the two losses that you have indicated in your screenshot.

  If you review this operation in your history in My IG you will see that it is displayed correctly. I advise you to open a technical issue with ProRealtime on this topic.

  3 users thanked author for this post.

  Paul, Nicolas, TempusFugit

  

  GraHal

  Participant

  Topics: 204

  Replies: 8399

  Been thanked: 2041 times
  07/13/2020 at 11:27 AM #139134
  TempusFugit

  Hi again,

  PRT just mailed me with this:

  Para su información, lo que la plataforma muestra no es realmente exacto, el problema está relacionado con el hecho de que dos órdenes fueron recibidas en el mismo segundo pero sin ninguna posibilidad por nuestra parte de definir el orden real de ejecución (porque IG Markets no especifica milisegundos).
  Aquí se han puesto dos órdenes en un orden que no es el orden de ejecución real (porque no podemos saberlo) lo que crea una visualización en la plataforma que no es la representación correcta de la realidad.

  It says that  IG send them two different orders in the same second and because IG doesn´t specifies the miliseconds they can´t know the right sequence of the orders. And that´s the reason of the wrong display in “closed orders” tab.

  I am guessing that this can happen when there is multiple entrys (like Paul) or change of direction (long to short or viceversa) AND ALSO different position sizes in the simultaneous orders.

  To be fair this time they gave me at least a reasonable explanation for the problem 🙂

  

  TempusFugit

  Participant

  Topics: 41

  Replies: 232

  Been thanked: 65 times
  07/13/2020 at 2:12 PM #139147
  GraHal

  For the record … PRT response in English (Tempus did an excellent summary above)

  For your information, what the platform shows is not really exact, the problem is related to the fact that two orders were received in the same second but without any possibility on our part to define the actual order of execution (because IG Markets did not specify milliseconds).
  Here two orders have been placed in an order that is not the actual order of execution (because we cannot know it) which creates a visualization on the platform that is not the correct representation of reality.

  

  GraHal

  Participant

  Topics: 204

  Replies: 8399

  Been thanked: 2041 times
  07/13/2020 at 2:15 PM #139149
  GraHal

  We still don’t know why the 2 Orders were needed in the first place  … or do we?? 🙂

  Also why is there a need to divide gain / loss between 2 orders??

  

  GraHal

  Participant

  Topics: 204

  Replies: 8399

  Been thanked: 2041 times
  07/14/2020 at 8:31 AM #139216
  TempusFugit

  Those are very good questions. I have a theory about it I can´t prove. It may be difficult to explain here, I´ll try anyway. Folowing the real orders I attached before and again here:

  1. Entry order of -0.92, despite appear as exit order in the log.
  2. Exit order of 0.58. Here is where the platform get mess up because instead of the actual exit order of 0.92 that happens in the same second it chosses the new entry order of 0.58 as exit. This -0.92/0.58 operation correspond to the closed order of -104.92€ in the list
  3. New entry order of 0.92, that actually it´s the exit of the 1st order. Here my guess is that the platform make the clearance of the previous -0.92/0.58 closed order and leaves the new 0.58 open order and the made up closed order of -61.51€
  4. The  final -0.58 exit order that seems to be the only one right

  If I am right about this, PRT could solve this problem matching the orders with the same position size -0.92/0.92 instead that chossing radomly the new 0.58 entry order as exit order.

  

  TempusFugit

  Participant

  Topics: 41

  Replies: 232

  Been thanked: 65 times
  07/14/2020 at 10:53 AM #139224
  GraHal

  Good analysis Tempus, thank you!

  This Topic is now a good record to refer the Community back to when they get similar anomalies.

   

  

  GraHal

  Participant

  Topics: 204

  Replies: 8399

  Been thanked: 2041 times
  07/15/2020 at 9:27 AM #139173
  TempusFugit

  GraHal wrote:

  We still don’t know why the 2 Orders were needed in the first place … or do we?? 🙂

  Also why is there a need to divide gain / loss between 2 orders??

  Those are very good questions and I have an hipotesis about it I can´t prove. It may difficult to explain here, I will try. Following the real case I attached before and again here:

  1. Entry order (despite appear as exit order in the log) of  -0.92 contracts
  2. Exit order of 0.58: Here is when the plataform get mess up with the orders because it puts this new entry order as exit order instead the actual exit order of 0.92. And this -0.92/0.58 operation corresponds to the first closed order in the list for -104.92€
  3. New entry order of 0.92 in the same second of the previous order. I guess here the platform makes a clearance with the previous closed order rest of -0.92/0.58 and leaves the actual 0.58 new order and the consequent made up closed order of -61.51€
  4. The final order of -0.58. The only one that seems to be right in the list

  If I am right this can be solved easily by PRT even if it doesn´t have the right sequence of orders just matching the two orders with the same position size, the 1 and 3, as entry/exit instead of putting randomly the 0.58 instead of the 0.92.

  

  TempusFugit

  Participant

  Topics: 41

  Replies: 232

  Been thanked: 65 times
• Author
  Posts