Skip to main content

Iceberg orders

Iceberg order is an order to conclude a transaction to buy/sell a specific number of lots of the price that the trader who placed the order considers acceptable with the possibility of portioning the lots into the order book.

Iceberg orders are a special case of limit orders and are processed according to the same rules, except one: the total volume of lots in the order can be split into parts and posted to the order book in portions, hiding the real order volume from other traders.

General information​

In addition to a number of properties inherited from limit orders, iceberg orders also have their own features that must be kept in mind:

Shared order book.

Iceberg orders are listed in the same order book as any other limit orders. There is no separate chart for them, which allows to somehow differentiate a new order from other orders or by which it would be possible to trace the number and volumes of other iceberg orders.

Collateral is blocked for the entire order, not just the visible part.

Although only a part of an iceberg order is placed in the chart at a time, collateral must cover the full order.

Example

The cost of a single lot is RUB 300. By placing an order for purchase with a total volume of 1,000 lots and a visible part of 100 lots, the bidder must provide collateral for the entire order, i.e. in the amount of RUB 300,000 (three hundred thousand).

Visible part doesn't have to be constant.

Iceberg order placement requires the use of two specific parameters: the size of the visible part and the deviation amplitude. The first parameter defines the number of lots displayed in the chart at the same time instead of the total order volume. The second parameter allows you to set the maximum size of the random increment in percentage of the specified visible quantity, so that the new visible volume differs from the previous consumed one.

caution

The ALOR Broker trading system allows using the deviation amplitude only for derivative market orders.

Example

Trader posts an order with a total volume of 1000 lots, a visible part of 100 lots and a deviation amplitude of 15%. Bids in the volume from 100 to 115 lots will be published in the chart for such order until the total volume of the order is covered.

Iceberg orders have their own limits.

Exchanges may set additional conditions for iceberg orders, which should be noted. For example, for Moscow Exchange, the ratio of the visible part to the total order volume must be at least 1:100, and the minimum amount of the visible part in cash value must be at least RUB 30,000. The amplitude of the deviation should be no more than 20% of the size of the visible part.

Example

Trader posts an order with a total volume of 1000 lots. The price of a single lot is RUB 300. Although the minimum ratio of the visible part to the total volume allows setting the visible part at 10 lots, the volume of the visible part shall not be less than 100 lots due to the minimum threshold of the cash value of the visible volume and the price of one lot.

Trader should be ready for a price bounce.

After covering the entire volume or canceling an order, there may be a sudden change of the instrument's price, as there is nothing to keep it at the same level with the same trading dynamics.

Experienced traders can detect iceberg orders.

The main task of the iceberg is to hide the total order volume from other traders. Nevertheless, an experienced Trader, knowing the order rules and having a close look at the market, can detect an iceberg order, assume its total volume and adjust his actions according to this knowledge.

Пример

Monitoring the market, trader noticed the following situation: the order book always has an order of 100 to 120 lots at the same price level of RUB 300 per lot, which is placed repeatedly when the previous one is covered. Analyzing the possibility of a mere coincidence, an experienced trader can assume the presence of an order with a total volume of up to 10000 lots in the order book.

Order collateralization

Limit order must be collateralized in accordance with the client's risk level and trading method:

  • In case of non-marginal trading the collateral for the order shall be the full value of the order;

  • For margin trading, collateral depends on the client's level of risk.

You can check the sufficiency of funds by the order evaluation request. To find out the terms and conditions of the order collateral depending on the risk level, click here.

Iceberg order should be considered as an opportunity to hide your intentions of a large purchase or sale from other traders. However, it should be remembered that experienced traders can recognize such orders by indirect signs and use it in their favor.

If this method does not match the trading strategy you use, we recommend to try market and limit orders instead.

Conditions​

The main condition for order execution is the timeInForce parameter, which regulates the processing of the order balance after exhaustion of all counter offers of the market. Possible values:

Condition

Description

oneday

Order shall be valid during the trading day. The balance after withdrawal of the entire available volume of counter offers shall be placed in the queue for execution and shall be held until order fulfillment, cancellation or the end of the trading day within which the order was placed.

goodtillcancelled

Similar to oneday, but with no time limit — the balance is held in the queue until the order is complete or canceled.

immediateorcancel

Order is fulfilled for the volume available at the moment of placement, the rest is canceled.

fillorkill

Order can be fulfilled only in its entirety. If the available volume does not allow to fulfill the order, it will not be placed at all.

Request examples​

Общие требования​

An order through the API can be posted, changed and canceled if it has not been executed before. In this case, regardless of the selected action and interaction protocol, all requests must:

  • be authorized
  • be identifiable
  • contain a message with all order parameters

How these conditions should be met, however, depends on the interaction protocol.

Authorization

Authorization is necessary to confirm that the sender has the rights to use the requested resource. Request authorization uses a JWT token, which acts as an Access token. A full description of available authorization methods is available in the Authorization section.

HTTP API uses the Authorization header parameter to pass the token. The header must be passed with each executed request.

This token should be passed as a Bearer token, so the header must contain the Bearer prefix before the passed value. A correctly filled Authorization header looks as follows:

Authorization: Bearer eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIsImN0eSI6IkpXVCJ9.eyJzdWIiOiJMb2dpblNhbXBsZSIsImVudCI6ImNsaWVudCIsImVpbiI6IjAxMjM0IiwiY2xpZW50aWQiOiIwMTIzNDU2IiwiYXpwIjoiMDEyMzQ1Njc4OWFiY2RlZjAxMjMiLCJhZ3JlZW1lbnRzIjoiQWdyZWVtZW50U2FtcGxlMSBBZ3JlZW1lbnRTYW1wbGUyIEFncmVlbWVudFNhbXBsZTMiLCJwb3J0Zm9saW9zIjoiUG9ydGZvbGlvU2FtcGxlMSBQb3J0Zm9saW9TYW1wbGUyIFBvcnRmb2xpb1NhbXBsZTMiLCJzY29wZSI6Ik9yZGVyc1JlYWQgT3JkZXJzQ3JlYXRlIFRyYWRlcyBQZXJzb25hbCBTdGF0cyIsImV4cCI6Mjg3MTc2MzE5OSwiaWF0IjowLCJpc3MiOiJBbG9yLklkZW50aXR5IiwiYXVkIjoiQ2xpZW50IFdBUlAgV2FycEFUQ29ubmVjdG9yIHN1YnNjcmlwdGlvbnNBcGkgQ29tbWFuZEFwaSBJbnN0cnVtZW50QXBpIFRyYWRpbmdWaWV3UGxhdGZvcm0ifQ.QOQVMIAoZ6SnF5urnIzJ0EvtQd9P5Sx355069kXoID207wHOTW0wkKNMcrIKXmENEQQ_0yDjqH_kjeqWLBJuqA

Identification

Request identification is needed to sort out a dozen of similar requests into unique ones. The identifier must be provided by the user and passed as a value of the X-REQID header parameter, so the API client used must be able to generate it.

Any character combination can be used as a request identifier, including the wildcard characters !@##;%:?*()-_=+/|''. Identifier has two restrictions:

  • The identifier value must be unique for the trading system. If the value has been previously used for another request, a copy of the response to the first request with this identifier will be returned instead of execution of the new request

  • Wildcard characters that violate the integrity of a JSON object must be escaped

Thus, the system will accept both Dxxxxx-Order-Market-No-812643-@-MOEX and d3c886f1-ea1e-4634-aff4-119c902ad926 as the request identifier, provided that these values have not been previously passed to the system by any API user.

A properly filled X-REQID parameter does not require any additional prefixes and looks as follows:

X-REQID: d3c886f1-ea1e-4634-aff4-119c902ad926

Order management​

Interchangeability

Order management options are interchangeable. For example, an order placed via HTTP API can be changed or canceled via WebSocket API, and vice versa.

Creating order

Interactive description

Interactive description of this request is available at the Create Limit order page

An iceberg order can be posted via HTTP API just like a regular limit order: by POST request to the /commandapi/warptrans/TRADE/v2/client/orders/actions/limit endpoint.

Complete URL looks as follows:

https://api.alor.ru/commandapi/warptrans/TRADE/v2/client/orders/actions/limit
https://apidev.alor.ru/commandapi/warptrans/TRADE/v2/client/orders/actions/limit

But the message body, which is mostly similar to a regular limit order, should contain two additional parameters: icebergFixed (the visible part of the order) and icebergVariance (the amplitude of the deviation in percent of the visible part).

Request body example
{
  "side": "buy",
  "quantity": 1000,
  "price": 301.74,
  "instrument": {
    "symbol": "SBER",
    "exchange": "MOEX",
    "instrumentGroup": "TQBR"
  },
  "comment": "Custom comment",
  "user": {
    "portfolio": "D39004"
  },
  "timeInForce": "oneday",
  "icebergFixed": 100,
  "icebergVariance": 10
}
Expected result

An iceberg order was created to buy 1000 lots of SBER on the Moscow Exchange (MOEX) in T+2 mode (TQBR) at a price of RUB 301.74 per lot.

The visible part of the iceberg is 100 lots with a maximum variance of 10% (up to 110 lots total).

If the request is successful, the API will return a message with response code 200 containing the exchange order number:

Response body example
{
  "message": "success",
  "orderNumber": "189...559"
}

If the request processing ended with an error, the API will return information about the cause of this error.

Request parameters

A complete list of all parameters and possible responses is available on the request description page.

Changing order

Interactive description

Interactive description of this request is available at the Update Limit order page

To change a previously posted order via the HTTP API, a PUT request to the /commandapi/warptrans/TRADE/v2/client/orders/limit/{orderId} endpoint is used, where {orderId} is a Path parameter that passes the order number.

How the order will be changed?

Modification of the order is made by canceling the previously placed order and publishing a new one. It is not possible to change fulfilled or canceled orders.

Complete URL looks as follows:

https://api.alor.ru/commandapi/warptrans/TRADE/v2/client/orders/actions/limit/189...559
https://apidev.alor.ru/commandapi/warptrans/TRADE/v2/client/orders/actions/limit/189...559

Where 189...559 is the actual value of the {orderId} parameter.

When changing an existing order, a message identical to the order posting request is used. The difference is in other parameter values.

Request body example
{
  "side": "buy",
  "quantity": 1000,
  "price": 301.74,
  "instrument": {
    "symbol": "SBER",
    "exchange": "MOEX",
    "instrumentGroup": "TQBR"
  },
  "comment": "Custom comment",
  "user": {
    "portfolio": "D39004"
  },
  "timeInForce": "oneday",
  "icebergFixed": 150,
  "icebergVariance": 20
}
Expected result

The order with the number 189...559 has been canceled. A new iceberg order to buy 1000 lots of the SBER instrument on the Moscow Exchange (MOEX) in the T+2 (TQBR) mode at the price of RUB 301.74 per lot has been created. The visible part of the order should be 150 lots with a maximum deviation of 20% (up to 180 lots in total).

If the request is successful, the previous order will be canceled and the API will return a message with response code 200 containing the exchange number of the new order:

Response body example
{
  "message": "success",
  "orderNumber": "189...560"
}

If the request processing ended with an error, the API will return information about the cause of this error.

Request parameters

A complete list of all parameters and possible responses is available on the request description page.

Cancelling order

Interactive description

Interactive description of this request is available at the Cancel one order page

What orders can be canceled?

Only pending orders can be canceled. It is impossible to cancel fulfilled orders.

To cancel a previously posted order via HTTP API, a DELETE request to the /commandapi/warptrans/TRADE/v2/client/orders/{orderId} endpoint is used, where {orderId} is a Path parameter that passes the order number.

In addition to the order number, the following attributes of the order are also required:

Query parameters

    portfolio stringrequired

    Client portfolio Id

    Example: D39004
    exchange stringrequired

    Possible values: [MOEX]

    Exchange code

    stop booleanrequired

    Is it a stop order?

    Example: false

So, the complete URL of the request to cancel the order looks as follows:

https://api.alor.ru/commandapi/warptrans/TRADE/v2/client/orders/189...560?portfolio=D39004&exchange=MOEX&stop=false
https://apidev.alor.ru/commandapi/warptrans/TRADE/v2/client/orders/189...560?portfolio=D39004&exchange=MOEX&stop=false
Expected result

Order with number 189...560 has been canceled.

If the request is successful, the previous order will be canceled and the API will return a message with response code 200:

success

If the request processing ended with an error, the API will return information about the cause of this error.

Request parameters

A complete list of all parameters and possible responses is available on the request description page.

Группы заявок

If necessary, a limit order can be grouped with other orders for cohesive execution.

What's next?​

Additionally, we recommend reading the following related articles: