System protection
Some user actions — intentional or not — can harm both the system and the users themselves. To prevent negative consequences for all parties, the system serves several independent protective mechanisms.
Social Rating
The social rating mechanism protects the system from potential overloads caused by users and their trading robots. The principle is simple: each action is assigned a point cost, and reaching the limit results in a temporary block.
How the mechanism works
Scoring in the social rating mechanism uses two independent counters, split across different sections of the system: one for market data requests (quotes, anonymous trades, etc.), and the other for order management requests (including receiving data about them).
In addition to different sections of the system, counters also differ in terms of the interfaces they monitor. For example, the market data section counter monitors only WebSocket, while the order management section counter monitors WebSocket and REST requests. Exceeding the limit blocks access to all monitored interfaces of the system section. GraphQL API is not monitored by any of the counters.
Counters are associated with the client's login, and therefore apply to all portfolios and markets within the designated section. When the limit is reached, each counter blocks access only to the interfaces and section of the system for which it is responsible. Thus, blocked market data access will not prevent the user from placing orders or requesting data through another interface.
Restrictions are temporary and will be removed automatically 2 hours after applying. If the problem has been resolved earlier, the user can be unbanned via technical support.
Counters are reset in two cases:
- At the start of a new day;
- When the block is removed.
However, note that the counters not only accumulate points independently of each other, but also reset them. For example, unlocking one counter will not affect the other.
Ban imposed by the mechanism has no consequences other than temporary inability to access one of the system sections. However, if we suspect any abuse, we still have the right to take the necessary actions.
Actions and point costs
Due to security reasons, we do not publish a complete list of tracked actions. However, the table below provides examples of tracked actions and their actual point costs:
| Action | Cost (points) |
|---|---|
| WebSocket connection established | 1 |
| Subscription to a data stream | 1 |
| Message buffer overflow on subscription | 1000 |
| Request for a non-existent order | 100 |
| Request serialization error (invalid JSON) | 5000 |
The list of tracked actions and their point costs may change without notice.
Limit
The description of the social rating mechanism mentions a point limit, upon reaching which the user will be blocked, but the exact value is not specified. The reason is to avoid situations where users would only formally comply with the limit, balancing on the edge.
Quick summary
- Applies across all exchange sections;
- Uses two counters: for market data requests and order management commands;
- Tracks both erroneous and valid actions;
- Counters are independent and accumulate points separately;
- Market data counter monitors WebSocket only; order management counter covers WebSocket and REST;
- Different actions have different point costs (counter fill rates);
- Exceeding the point limit temporarily blocks access to the corresponding system section;
- A block by one counter does not affect functionality covered by the other;
- Block duration is 2 hours;
- Blocks can be removed early via technical support;
- No consequences beyond temporary blocking, unless malicious intent is detected — in such cases, additional actions may apply.
Protective Blocking on FORTS
The Moscow Exchange may apply its own measures against users sending large volumes of clearly unexecutable requests: from additional fee to temporary login block.
The FORTS protection mechanism task is to help users minimize the consequences of their erroneous actions.
The mechanism counts errors returned by the exchange. Blocking the user helps reduce downstream consequences but does not eliminate them.
How the mechanism works
The FORTS protection mechanism uses separate counters, one for each tracked error type. Reaching the limit on any counter restricts the user’s access to order management until the cause of restrictions is resolved.
The mechanism applies only to the futures market and does not affect other exchange sections — errors from other markets are ignored and do not trigger restrictions. On the futures market, all errors via HTTP API and WebSocket are tracked. GraphQL API is not monitored due to the nature of the tracked request types.
Counters operate independently — their values are not summed. A user will not be blocked even if all counters are at limit - 1. However, reaching the limit by multiple counters results in consecutive blocks.
Blocks are temporary and automatically removed after the duration specified for the error type. Early unblocking is not available. After a block is removed, a 60-second cooldown period begins: the system continues to count errors but does not apply new blocks. If the limit is exceeded during this time, a new block is applied immediately after the cooldown.
Counters are reset in two cases:
- At the start of a new day;
- When the block is removed.
Importantly, counters accumulate and reset independently. For example, removing a block for "Order not found" does not affect the "Instrument not found" counter.
Resetting counters in our system does not affect the exchange. If the mechanism has blocked a user three times for "Order not found" errors, the exchange has already recorded at least 1200 penalty points for its own calculations.
Actions and point costs
The protective blocking mechanism tracks the same error types as the exchange. The difference lies in the allowed thresholds:
| Error type | Limit | Blocking time, sec. |
|---|---|---|
Trading session suspended or closed | 400 | 1800 |
Security not found | 400 | 1800 |
Unspecified (or unknown) error from exchange | 2000 | 1800 |
Cross deal occurred | 400 | 1800 |
Insufficient client funds | 400 | 1800 |
Insufficient brokerage firm funds | 400 | 1800 |
FOK order not reconciled | 400 | 1800 |
Order not found | 400 | 1800 |
The Transaction completed successfully and no orders (0) deleted error type is not currently tracked by the mechanism. Be careful when sending a request to cancel all orders.
The list of tracked actions, their costs, limits, and block durations may change without notice.
Quick summary
- Applies only to the futures market, not affecting other exchange sectors;
- Each error type has its own counter;
- Reaching the limit temporarily blocks trading access on the futures market. Limits and block durations are listed above;
- Blocks are removed automatically only — manual unblocking is not available;
- Lifting a block resets only the counter that triggered it, making subsequent blocks on other counters possible;
- After a block is removed, a 60-second cooldown period begins: errors are counted but no new block is applied;
- All errors recorded by the mechanism are also recorded by the exchange and used in its penalty fee calculations.