Skip to main content

Documentation Index

Fetch the complete documentation index at: https://takeprofit.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

This article describes several aspects of our backtesting system and will help you write more accurate and reliable strategies.

​
Order execution

When trading on a real exchange, your actions cannot be executed instantly. It takes time for a request to reach the exchange, for the order to be added to the order book, for it to be executed, and for the execution notification to return to you. When writing and backtesting strategies, traders often overlook these delays and fail to account for them. As a result, a strategy may behave very differently in live trading compared to backtesting. To address this, our backtesting engine simulates these real-world delays. This means that actions in your code do not take effect immediately. Instead, they are applied with a delay, and the results of those actions become visible only on the next price tick, when the strategy is recalculated. The following examples illustrate how these delays affect strategy behavior in different scenarios:

​
Example 1: Order submission delay

When you create an order, it is not filled immediately. The order must first be sent to the exchange, accepted, and then executed. This example demonstrates that you cannot see the filled status immediately after calling submit(): 
# indie:lang_version = 5
from indie import strategy, MainStrategyContext, Optional, IndieError
from indie.strategies import order_side, Order, order_status

@strategy('Order Submission Delay')
class Main(MainStrategyContext):
    def __init__(self):
        self._order: Optional[Order] = None
        self._step = 0

    def calc(self):
        if self._step == 0:
            # Create an order
            self._order = self.trading.place_order(order_side.BUY, size=1).submit()
            # Check: order should NOT be filled immediately
            if self._order.value().status == order_status.FILLED:
                raise IndieError('Order should not be filled immediately after creation')
            self._step = 1
        elif self._step == 1:
            # On the next calc call, the order should be filled
            if self._order.value().status != order_status.FILLED:
                raise IndieError('Order should be filled by now')
            self._step = 0

​
Example 2: Order update delay

When you update an order’s parameters (e.g., limit price), the changes are not applied immediately. This example shows that the order properties reflect the update only on the next calc() call: 
# indie:lang_version = 5
from indie import strategy, MainStrategyContext, Optional, IndieError
from indie.strategies import order_side, Order, order_status

@strategy('Order Update Delay')
class Main(MainStrategyContext):
    def __init__(self):
        self._order: Optional[Order] = None
        self._step = 0

    def calc(self):
        if self._step == 0:
            # Create an order with a limit price that won't execute
            self._order = (
                self.trading.place_order(order_side.SELL, size=1).
                limit(self.high[0] * 10).
                submit()
            )
            self._step = 1
        elif self._step == 1:
            # Update the limit price to a value that will execute
            new_limit = self.low[0] / 10
            (
                self.trading.amend_order(self._order.value().id).
                limit(new_limit).
                submit()
            )
            # Check: the limit should NOT be updated immediately
            if self._order.value().limit.value() == new_limit:
                raise IndieError('Order cannot be updated immediately')
            self._step = 2
        elif self._step == 2:
            # On the next calc call, the new limit should be applied and order filled
            if self._order.value().limit.value() >= self.high[0]:
                raise IndieError('Order limit was not updated correctly')
            if self._order.value().status != order_status.FILLED:
                raise IndieError('Order should be filled by now')
            self._step = 0

​
Example 3: Order cancellation delay

When you cancel an order, it is not canceled immediately. The cancellation request must be sent to the exchange and processed. This example demonstrates the delay: 
# indie:lang_version = 5
from indie import strategy, MainStrategyContext, Optional, IndieError
from indie.strategies import order_side, Order, order_status

@strategy('Order Cancellation Delay')
class Main(MainStrategyContext):
    def __init__(self):
        self._order: Optional[Order] = None
        self._step = 0

    def calc(self):
        if self._step == 0:
            # Create an order with a limit price that won't execute
            self._order = (
                self.trading.place_order(order_side.SELL, size=1).
                limit(self.high[0] * 10).
                submit()
            )
            self._step = 1
        elif self._step == 1:
            # Cancel the order
            self.trading.cancel_order(self._order.value().id)
            # Check: order should NOT be canceled immediately
            if self._order.value().status == order_status.CANCELED:
                raise IndieError('Order should not be cancelled immediately')
            self._step = 2
        elif self._step == 2:
            # On the next calc call, the order should be canceled
            if self._order.value().status != order_status.CANCELED:
                raise IndieError('Order should be cancelled by now')
            self._step = 0

​
Example 4: Immediate update after creation

When you create and immediately update an order in the same calc() call, the system applies the update locally before sending the order to the exchange. This means the order is sent with the updated parameters: 
# indie:lang_version = 5
from indie import strategy, MainStrategyContext, Optional, IndieError
from indie.strategies import order_side, Order, order_status

@strategy('Immediate Update After Creation')
class Main(MainStrategyContext):
    def __init__(self):
        self._order: Optional[Order] = None
        self._step = 0

    def calc(self):
        if self._step == 0:
            # Create an order with a high limit price
            self._order = (
                self.trading.place_order(order_side.SELL, size=1).
                limit(self.high[0] * 10).
                submit()
            )
            # Immediately update it to a price that will execute
            new_limit = self.low[0] / 10
            (
                self.trading.amend_order(self._order.value().id).
                limit(new_limit).
                submit()
            )
            self._step = 1
        elif self._step == 1:
            # On the next calc call, the order should have the updated limit and be filled
            # NOTE: When you create and modify an order in the same calc call,
            # the update is applied locally before the order is sent to the exchange.
            # The exchange receives the order with the already updated parameters.
            if self._order.value().limit.value() >= self.high[0]:
                raise IndieError('Order limit was not updated correctly')
            if self._order.value().status != order_status.FILLED:
                raise IndieError('Order should be filled by now')
            self._step = 0
Key takeaway: Always account for execution delays when writing strategies. Order operations (creation, updates, cancellations) take effect on the next calc() call, not immediately. This behavior ensures your strategy works more consistently in both backtesting and live trading environments.

​
Fail-safe order operations

Some operations performed by a strategy — such as canceling or updating an order — are handled safely. This means the strategy will not fail if you call cancel or amend on an order that has already been canceled or executed. In such cases, the invalid operation is simply ignored. This simplifies your code and removes the need for additional if statements in situations where you want to “cancel an order if it hasn’t been executed or canceled yet” or “update an order if it’s still active”. The example below demonstrates a strategy that places sell limit orders and then cancels or updates them based on price movement — without checking the order status before each operation: 
# indie:lang_version = 5
from indie import strategy, MainStrategyContext, Optional
from indie.strategies import order_side, Order, order_status


@strategy('Fail-Safe Order Operations', overlay_main_pane=True)
class Main(MainStrategyContext):
    def __init__(self):
        self._sell_order: Optional[Order] = None

    def calc(self):
        if self.close[0] < self.close[1]:  # price starts falling -> place sell order
            if self._sell_order is None or self._sell_order.value().status == order_status.FILLED:
                limit_price = self.close[0] * 0.99
                self._sell_order = (
                    self.trading.place_order(order_side.SELL, size=1).
                    limit(limit_price).
                    submit()
                )
        elif self.close[0] > self.close[3]:  # price rising during three bars -> cancel sell order
            if self._sell_order is not None:
                # Note: we don't check if the order was already filled or canceled
                # The system will safely ignore the cancellation if the order is no longer active
                self.trading.cancel_order(self._sell_order.value().id)
                self._sell_order = None
        elif self.close[0] > self.close[1]:  # short price correction -> we can sell at a better price -> update order
            if self._sell_order is not None:
                # Note: we don't check if the order was already filled
                # The system will safely ignore the amend operation if the order is no longer active
                new_limit_price = self.close[0] * 0.99
                (
                    self.trading.amend_order(self._sell_order.value().id).
                    limit(new_limit_price).
                    submit()
                )
Key takeaway: In this example, we call both cancel_order() and amend_order() without explicitly checking the order status beforehand. If the order has already been filled, canceled, or rejected, these operations will be safely ignored without throwing an exception. This simplifies your code by removing the need for defensive status checks.

​
Order filtering (intrabar_order_filter parameter)

Inside a bar, the price moves. While the current candle is not finished, the strategy receives updates for the current candle. The strategy does not remember all intermediate values; only the latest, most actual value of the current candle is available in the strategy. If the logic of the strategy is based on comparing the current candle with the previous closed candle, then you may get false positive triggers. They can be avoided by additional checks in the code or by using our pre-configured filter intrabar_order_filter. Possible values for intrabar_order_filter:
  • intrabar_order_filter.NO_FILTER: No intrabar filtering is applied. Orders can be placed or modified at any price update within a candle.
  • intrabar_order_filter.ON_BAR_CLOSE: Orders can be placed or modified only at the close of the candle. Other submits of place_order will be rejected with the REJECTED status.
  • intrabar_order_filter.FIRST_IN_BAR: Only the first batch of orders within a bar is accepted. Orders can be placed on any price update, but once a calc() call places orders, all orders from subsequent calc() calls within the same bar are ignored (rejected with the REJECTED status).
  • intrabar_order_filter.LAST_IN_BAR: Only the last batch of orders within a bar is applied. All orders placed during a calc() call are accepted, but if a new calc() call places orders, the previous batch is replaced by the new one. The final batch is applied when the next bar starts.
Let’s look in more detail with an example. Suppose the price changes like this: 
    candle1    |    candle2     |    candle3     |
41.0 41.4 41.8 | 42.2 42.6 43.0 | 43.4 43.8 44.2 |

# 3 price updates during each candle
We want to place an order when the price crosses the 42.0 level: 
    candle1    |    candle2     |    candle3     |
41.0 41.4 41.8 | 42.2 42.6 43.0 | 43.4 43.8 44.2 |
                  ^
      42.2 > 42.0 and 41.8 < 42.0
          crossing detected,
            order placing
We want to write code like this: 
# current price is above the level and previous candle closed below it
if self.close[0] > 42.0 and self.close[1] < 42.0:
    self.trading.place_order(...).submit()
But the strategy’s Main function is called on each price update, not only on bar close. Since we compare the current price to the previous bar’s close, this will result in extra triggers: 
    candle1    |                 candle2                  |    candle3     |
41.0 41.4 41.8 | 42.2              42.6              43.0 | 43.4 43.8 44.2 |
                  ^                 ^                 ^
             42.2 > 42.0       42.6 > 42.0       43.0 > 42.0
             41.8 < 42.0       41.8 < 42.0       41.8 < 42.0
           cross detected    cross detected    cross detected
Therefore, we need to add extra logic to prevent duplicate orders. Depending on the specific situation, different approaches may be appropriate.

​
Manual trigger filtering: previous price comparison

We can compare it not with the previous bar’s price but with the last received tick price, if you store it in a variable: 
# indie:lang_version = 5
from indie import strategy, MainStrategyContext
from indie.strategies import intrabar_order_filter

@strategy('Manual Filter - Previous Price Comparison', intrabar_order_filter=intrabar_order_filter.NO_FILTER)
class Main(MainStrategyContext):
    def __init__(self):
        self._prev_price = 0.0

    def calc(self):
        if self.bar_index > 0:
            if self._prev_price < 42.0 and self.close[0] > 42.0:
                self.trading.place_order(...).submit()
        self._prev_price = self.close[0]

​
Manual trigger filtering: trigger at bar close

We can detect the crossing and place an order only at bar close: 
# indie:lang_version = 5
from indie import strategy, MainStrategyContext
from indie.strategies import intrabar_order_filter

@strategy('Manual Filter - Bar Close Trigger', intrabar_order_filter=intrabar_order_filter.NO_FILTER)
def Main(self):
    if self.is_closed_bar:
        if self.close[1] < 42.0 and self.close[0] > 42.0:
            self.trading.place_order(...).submit()

​
Manual trigger filtering: only first trigger during bar

We can ensure that only one order is placed per bar (not necessarily at bar close): 
# indie:lang_version = 5
from indie import strategy, MainStrategyContext
from indie.strategies import intrabar_order_filter

@strategy('Manual Filter - First Trigger Only', intrabar_order_filter=intrabar_order_filter.NO_FILTER)
class Main(MainStrategyContext):
    def __init__(self):
        self._last_order_time = 0.0

    def calc(self):
        if self._last_order_time < self.time[0] and self.close[1] < 42.0 and self.close[0] > 42.0:
            self.trading.place_order(...).submit()
            self._last_order_time = self.time[0]
But all of these approaches require additional logic in the code. To avoid writing extra checks, we introduced several pre-configured filters for controlling when orders are placed.

​
intrabar_order_filter.ON_BAR_CLOSE

To place orders only at bar close: 
# indie:lang_version = 5
from indie import strategy, MainStrategyContext
from indie.strategies import intrabar_order_filter

@strategy('Auto Filter - On Bar Close', intrabar_order_filter=intrabar_order_filter.ON_BAR_CLOSE)
def Main(self):
    # not necessary to manually check if it is a closed bar
    if self.close[1] < 42.0 and self.close[0] > 42.0:
        self.trading.place_order(...).submit()

​
intrabar_order_filter.FIRST_IN_BAR

Only the first batch of orders within a bar is accepted. Orders can be placed on any price update, but once a calc() call places orders, all orders from subsequent calc() calls within the same bar are ignored until the next bar. You can place multiple orders in the same calc() call and they will all go through. The same rules apply to cancel_order and amend_order — see below. 
# indie:lang_version = 5
from indie import strategy, MainStrategyContext
from indie.strategies import intrabar_order_filter

@strategy('Auto Filter - First In Bar', intrabar_order_filter=intrabar_order_filter.FIRST_IN_BAR)
def Main(self):
    # not necessary to store the last order time
    if self.close[1] < 42.0 and self.close[0] > 42.0:
        self.trading.place_order(...).submit()

​
intrabar_order_filter.LAST_IN_BAR

Only the last batch of orders within a bar is applied. You can place multiple orders in the same calc() call and they will all be accepted, but if a new calc() call places orders, the entire previous batch is replaced by the new one. The final batch is applied when the next bar starts. The same rules apply to cancel_order and amend_order — see below. 
# indie:lang_version = 5
from indie import strategy, MainStrategyContext
from indie.strategies import intrabar_order_filter

@strategy('Auto Filter - Last In Bar', intrabar_order_filter=intrabar_order_filter.LAST_IN_BAR)
def Main(self):
    # not necessary to store the last order time
    if self.close[1] < 42.0 and self.close[0] > 42.0:
        self.trading.place_order(...).submit()
Note that to determine the last batch of orders within the bar, the emulator waits for the bar to close and then applies the final batch before placing orders on the next bar.

​
intrabar_order_filter.NO_FILTER

Finally, if none of these filters fit your needs and you want full control over when orders are placed, you can use the NO_FILTER setting, as shown in the examples above.

​
How filtering applies to cancel_order and amend_order

The intrabar_order_filter parameter controls not only place_order, but also cancel_order and amend_order commands. The filtering rules are the same as for order placement:
  • NO_FILTER: cancel_order and amend_order are accepted on any price update and applied on the next tick.
  • ON_BAR_CLOSE: cancel_order and amend_order calls are only accepted at bar close. Calls during intrabar ticks are silently ignored.
  • FIRST_IN_BAR: The first batch of cancel_order/amend_order calls in a bar is accepted. You can issue multiple commands in the same calc() call and they will all go through. Commands from subsequent calc() calls within the same bar are ignored.
  • LAST_IN_BAR: All cancel_order/amend_order calls within a calc() call are accepted as a batch. If a new calc() call issues commands, the entire previous batch is replaced. The final batch is applied when the next bar starts.
For example, with FIRST_IN_BAR you can cancel two orders in a single calc() call and both will be canceled. But if you cancel one order on the first price update and try to cancel another on the next update, the second cancel will be ignored: 
# indie:lang_version = 5
from indie import strategy, MainStrategyContext, Optional
from indie.strategies import order_side, Order, order_status, intrabar_order_filter


@strategy('Cancel/Amend with FIRST_IN_BAR', intrabar_order_filter=intrabar_order_filter.FIRST_IN_BAR)
class Main(MainStrategyContext):
    def __init__(self):
        self._order_a: Optional[Order] = None
        self._order_b: Optional[Order] = None

    def calc(self):
        if self._order_a is not None and self._order_b is not None:
            # Both cancels are in the same calc() call — both will be accepted
            self.trading.cancel_order(self._order_a.value().id)
            self.trading.cancel_order(self._order_b.value().id)
With LAST_IN_BAR, if you cancel an order on one price update and then cancel a different order on the next update, the first cancel is replaced by the second — only the second cancel will be applied when the next bar starts.

​
Price for market orders (market_order_price parameter)

By default, market orders are executed at the price the instrument has at the moment of execution. Note that the execution time of an order does not match the moment you place it or the moment you call place_order() (see the Order execution section above). This behavior reflects real-world execution, but during backtesting traders sometimes want to force a specific execution price for testing purposes. You can configure which value will be used as the execution price for market orders. There are three available options: 
# indie:lang_version = 5
from indie import strategy, MainStrategyContext
from indie.strategies import market_order_price

@strategy('Market Order at Creation Price', market_order_price=market_order_price.ORDER_CREATION_PRICE)
def Main(self):
    pass
This setting applies to the entire strategy run. It cannot be changed at runtime, so all market orders within a single run use the same configuration.

​
Simulation of trading at market close

The configuration described above can be useful when you want to simulate trading at market close using a price close to the bar’s closing value. To achieve this, you should place an order right before the session ends, using the bar’s closing price. This can be done by combining the market_order_price and intrabar_order_filter parameters. 
# indie:lang_version = 5
from indie import strategy, MainStrategyContext
from indie.strategies import order_side, market_order_price, intrabar_order_filter


@strategy('Trading at Market Close',
          intrabar_order_filter=intrabar_order_filter.ON_BAR_CLOSE,
          market_order_price=market_order_price.ORDER_CREATION_PRICE)
def Main(self):
    # just buying at the bar closing price
    self.trading.place_order(order_side.BUY, size=42.0).submit()

​
Simulation of trading at market open

Similarly, by combining the market_order_price and intrabar_order_filter parameters, you can execute an order at the current bar’s opening price to simulate trading at market open. 
# indie:lang_version = 5
from indie import strategy, MainStrategyContext
from indie.strategies import order_side, market_order_price, intrabar_order_filter


@strategy('Trading at Market Open',
          intrabar_order_filter=intrabar_order_filter.FIRST_IN_BAR,
          market_order_price=market_order_price.BAR_OPEN_PRICE)
def Main(self):
    # just buying at the bar opening price
    self.trading.place_order(order_side.BUY, size=42.0).submit()

​
Margin trading (leverage parameter)

Margin trading allows traders to borrow funds to increase their buying power, enabling them to open positions larger than their available capital. This is achieved by leveraging the trader’s initial capital as collateral. If the leverage parameter is greater than 1.0, the strategy can open positions larger than the available capital.
  • Leverage: The ratio of the trader’s position size to their own capital. For example, a leverage of 2.0 means the trader can open positions twice the size of their capital.
  • Initial margin: The minimum amount of the trader’s own funds required to open leveraged positions. If the portfolio value falls below the initial margin, the trader must reduce exposure. The trader cannot open new or increase existing uncovered positions.
  • Maintenance Margin: The amount of collateral at which positions are forcibly closed. The maintenance margin is usually 1/2 of the initial margin.
  • Equity: The trader’s total capital, including unrealized profits and losses, minus any liabilities.
  • Margin Call: A warning issued when equity falls below the initial margin, requiring the trader to add funds or reduce exposure to avoid liquidation.
  • Stop Out: The forced closure of positions when equity falls below the maintenance margin level.
Example Scenario: imagine a trader with $10,000 in capital and a max allowed leverage of 3.0. The trader opens a position worth $20,000 ($10,000 of their own and $10,000 provided by the broker on loan, current leverage is 2x). If the market moves against the trader and their equity falls below the initial margin requirement (e.g., $5,000), they will receive a margin call. If their equity continues to decline and falls below the maintenance margin requirement (e.g., $2,500), the broker will close the trader’s position to limit losses (stop-out). Risks of Margin Trading:
  • Amplified Losses: While leverage can increase profits, it also magnifies losses.
  • Liquidation Risk: Failure to meet margin requirements can result in the forced closure of positions.
  • Interest Costs: Borrowed funds may accrue interest, adding to the cost of trading.
Using leverage works best when it’s part of a clear plan: knowing how much risk you’re willing to take, how much the position can move against you, and when you’re ready to exit. Example of a strategy using leverage: 
# indie:lang_version = 5
from indie import strategy
from indie.strategies import order_side


@strategy(
    'Leverage Example', overlay_main_pane=True,
    initial_capital=100000.0, leverage=10.0)  # allow margin trading with 10x leverage
def Main(self):
    pos_size = self.trading.position.size
    if pos_size == 0:
        current_cash = self.trading.cash
        allowed_size_to_buy_with_own_money = current_cash / self.close[0]
        # we can buy more than our own money but not more than 10x
        order_size = allowed_size_to_buy_with_own_money * 2.0  # 2x leverage is OK, because 2 < 10

        # open the position with leverage
        self.trading.place_order(order_side.BUY, size=order_size).submit()
    else:
        # close the position
        self.trading.place_order(order_side.SELL, size=pos_size).submit()