The Moscow Exchange Introduces Charging for Erroneous Transactions (Part 2) - Trading stocks, futures, options and other exchange instruments

[Deleted] 2015.11.14 12:27 #41

11.2Charging for erroneous transactions.

Transactions shall be recognised as erroneous if during the course of the transaction an error code as set out in Table 2 has been assigned to it. For the purpose of determining erroneous transactions, a transaction is understood to mean submission of an Order, withdrawal of an Order, withdrawal of an Order with simultaneous submission of an Order with different Transaction conditions, withdrawal of a pair of Orders with simultaneous submission of a pair of Orders with different Transaction conditions.

The calculation of the Fee for Erroneous Transactions shall be made for each Login for the period from suspension of trading for the evening clearing session of the current Trading Day (including the first second of suspension) to suspension of trading for the evening clearing session of the next Trading Day (not including the first second of suspension) (hereinafter - the Calculation Period).

The calculation of the amount of the Fee for erroneous transactions shall be made according to the formula:

where:

TranFee2 - the amount of the Fee for erroneous transactions made during the Settlement Period (in roubles including VAT);

Cap - a limit on the maximum amount of the Fee for erroneous transactions set by the Technical Centre and published on the website of the Moscow Exchange;

xi- value calculated per second, rounded down to integers and determined by the formula:

where:

Qi- the sum of all points for the i-th second (points are determined in accordance with Table 2);

Li- the limit of the given login, which is calculated according to the formula and rounded to integers:

Where:

Capacityi- capacity of the login, determined in accordance with the procedure stipulated in point 3.2 of this Annex, valid for the i-th second.

Table 2:

Transaction type*	Result of execution (error code)*	Score Q
AddOrder	A cross transaction has occurred (31)	Q1
	Insufficient customer funds (332)	Q2
	Insufficient funds from brokerage firm (333)	Q3
	FOK bid not consolidated (4103)	Q4
DelOrder	Order not found (14)	Q5
MoveOrder	Cross-dealing occurred (31)	Q6
	Noorder wasfound (50)	Q7
	Insufficientcustomer funds(332)	Q8
	Insufficient fundsof the brokeragefirm (333)	Q9
DelUserOrders	The transaction was completed successfully, and no order is deleted	Q10

* in accordance with the description of the FORTS Plaza-2 Gateway.

Q1-Q10 point values are set by a decision of the Technical Centre and are published on Moscow Exchange's website.

A fee for erroneous Transactions will be charged if the condition is met:

where:

TranFee2 - the amount of the Fee for erroneous Transactions made during the Settlement Period (in roubles including VAT);

Capmin- a restriction on the minimum amount of the Fee for erroneous Transactions set by the Technical Centre and published on the website of the Moscow Exchange,

The Fee for erroneous Transactions is charged from the clearing register section to which the login for which the Fee for erroneous Transactions is determined is linked.

FORTS: Inefficient Transaction Fee Stop Loss doesn't work Fins in the glass

[Deleted] 2015.11.14 12:29 #42

Only the formulas are unfortunately not inserted.

kond777 2015.11.16 21:52 #43

Dmitriy Skub:
Do you want us to get drunk?)) Is it so hard to write a figure?

Alexey Kozitsyn copied just some of the text of this provision. Is it clearer now? )) I'm afraid you will still have to sleep if you want to understand it. ))

kond777 2015.11.18 16:12 #44

What is the return code for this error?

2015.09.21 10:00:13     20845617        SBRF-3.16       buy limit       2.00 / 0.00             7 303                   2015.09.21 10:00:13             rejected        Инструмент отсутствует в текуще

Mikhail Filimonov 2015.11.25 14:44 #45

Returning to the Invalid request error code

I have changed the function to delete the order a bit:

//+------------------------------------------------------------------+
// Remove order                                                      |
//+------------------------------------------------------------------+
void COrder::Remove()
{
  if ( ticket > 0 )
  {
    if ( OrderSelect( ticket ) )
    {
      ENUM_ORDER_STATE ord_state = ENUM_ORDER_STATE( OrderGetInteger( ORDER_STATE ) );
      if ( ( ord_state == ORDER_STATE_REQUEST_MODIFY ) || ( ord_state == ORDER_STATE_REQUEST_CANCEL ) ) return;
//---      
      mem_magic = ulong( OrderGetInteger( ORDER_MAGIC ) );
      mem_tick = GetTickCount();
      req_id = 0;
      MqlTradeRequest request = {0};
      MqlTradeResult  result  = {0};
            
      request.action = TRADE_ACTION_REMOVE;
      request.order = ticket;
          
      if ( OrderSendAsync( request, result ) )
      {
        if ( result.retcode == TRADE_RETCODE_PLACED )
        { 
          req_id = result.request_id;
//---          
          switch( order_status )
          {
            case BUY_ORDER:  state = ORD_BUY_DO_CANCEL;
                             break;
                
            case SELL_ORDER: state = ORD_SELL_DO_CANCEL;
                             break;           
          } 
          SetTransCount( true );
        }
        else
        {
          mem_magic = 0;
          mem_tick = 0;
          CheckError( result.retcode, "Remove: Ордер не удалён! Причина: ", order_status, ticket );
        }  
      }
      else
      {
        mem_magic = 0;
        mem_tick = 0;
        CheckError( result.retcode, "Remove: Ордер не отослан! Причина: ", order_status, ticket );
      }
    }
    else
    {
      ticket = 0;
      modify_count = 0;
    }
  }
  else
  {
    modify_count = 0;
  }
}

CheckError() function.

//+------------------------------------------------------------------+
// Expert Check Error function                                       |
//+------------------------------------------------------------------+
void CheckError( const uint ret_code, const string err_msg, const ENUM_ORD_STATUS ord_status, const ulong a_ticket )
{
  switch( ret_code )
  {
    ........                              
    case TRADE_RETCODE_INVALID: Print( err_msg + GetRetCode( ret_code ), "; Билет = ", a_ticket );
                                break;                                                       
                
    default: Print( err_msg, GetRetCode( ret_code ), "; Билет = ", a_ticket );  
             break;            
  }
}

After placing the order:

2015.11.25 15:07:30.773 Trades  'xxxxx': buy limit 5.00 SNGP-3.16 at 40718
2015.11.25 15:07:30.784 Trades  'xxxxx': buy limit 5.00 SNGP-3.16 at 40718 placed for execution in 10 ms

MT 5 server did not send any response, CheckOrders() function was triggered and an order ticket was received:

2015.11.25 15:07:31.849 Forts_trader (SNGP-12.15,H1)    CheckOrders: Buy ордер установлен. Билет = 23992887

After that, the command to delete the order (EA) did NOT go through:

2015.11.25 15:07:31.865 Forts_trader (SNGP-12.15,H1)    Remove: Ордер не отослан! Причина: Неправильный запрос Билет = 23992887

And this was also confirmed by the terminal:

2015.11.25 15:07:31.865 Trades  'xxxxx': failed cancel order #23992887 buy limit 5.00 SNGP-3.16 at 40718.00000 [Invalid request]

Question:

What is the status of the order in the terminal memory ?

Why Invalid request ?

I received a ticket from the terminal environment, so the terminal "knows" that the order is set!

After all, later the same function deleted this order with the same ticket:

2015.11.25 15:15:03.245 Trades  'ххххх': cancel order #23992887 buy limit 5.00 SNGP-3.16 at 40718
2015.11.25 15:15:03.254 Trades  'ххххх': cancel order #23992887 buy limit 5.00 SNGP-3.16 at 40718 placed for execution in 8 ms

Sergey Chalyshev 2015.11.25 15:13 #46

Михаил:

Returning to the Invalid request error code

I have changed the function to delete the order a bit:

CheckError() function.

After placing the order:

MT 5 server did not send any response, CheckOrders() function was triggered and an order ticket was received:

After that, the command to delete the order (EA) did NOT go through:

And this was also confirmed by the terminal:

Question:

What is the status of the order in the terminal memory ?

Why Invalid request ?

(I got the ticket from the terminal environment, so the terminal "knows that the order has been placed")!

There is also this:

2015.11.24 17:07:15.020 FORTS (MXI-12.15,M5)       ORDER_STATE = ORDER_STATE_REQUEST_ADD

Sergey Chalyshev 2015.11.25 15:23 #47

Try it this way:

if(!(OrderGetInteger(ORDER_STATE)==ORDER_STATE_PARTIAL || OrderGetInteger(ORDER_STATE)==ORDER_STATE_PLACED)) return;

Mikhail Filimonov 2015.11.25 15:25 #48

Sergey Chalyshev:

There are more of these:

Sergei!

For some reason it seems to me that if there is a ticket (after a warrant has been issued), there cannot be

its state:

ORDER_STATE_REQUEST_ADD

Sergey Chalyshev 2015.11.25 15:38 #49

Михаил:

Sergei!

Somehow it seems to me that if there is a ticket (after a warrant has been issued), there can't be

Its status:

I think so too, but it's not my idea, this error is from the transaction log.

After adding this check, put all states, before deletion and modification, in the log. InvalidRequest no longer occurs.

This question is more to the server operations and developers howORDER_STATE_REQUEST_ADD appears.

Questions from a "dummy" VPS disappeared from the Help! Disk Space Being

Mikhail Filimonov 2015.11.25 15:55 #50

Sergey Chalyshev:

I think so too, but it wasn't my idea, this error is from the operation log.

After adding this check, put all states, before deletion and modification, in the log. InvalidRequest no longer occurs.

This question is more to the server operations and developers howORDER_STATE_REQUEST_ADD appears.

There must be a rather long timeout in the terminal waiting for server's response...

FORTS: OnTradeTransaction() return codes - page 5