Skip to content
  • There are no suggestions because the search field is empty.

08. Usage examples

Rejecting orders

Case 1

Rejecting a certain type of orders for a group on a day of the week.
Rule:
  • Name
    BTCFridayReject
  • Actions
    • Action type
      Reject
  • Filter
    • Request types
      Market, Limit activation, Stop activation, Pending open
    • Directions
      Buy
  • Filter group 1
    • Name
      Group1BTC
    • Conditions
      • Accounts =
        Group1
      • Symbols =
        BTC*
      • Days =
        Friday
With this rule, placing a BTC* BUY order on Fridays will be impossible for the Group1 MetaTrader group.

Case 2

Rejecting placing pending orders at the specific hours of day.
Rule:
  • Name
    MiddayReject
  • Actions
    • Action type
      Reject
  • Filter
    • Request types
      Pending open
  • Filter group 1
    • Name
      Midday
    • Conditions
      • Accounts =
        *
      • Times ≥
        12:00
      • Times ≤
        13:00
Placing pending orders will be prohibited from 12:00 to 13:00.

Case 3

Rejecting trading activity around the server’s End Of Day timestamp.
Rule:
  • Name
    EODReject
  • Actions
    • Action type
      Reject
  • Filter
    • Request types
      Market, Instant, Pending activation
    • Entry type
      *
  • Filter group 1
    • Name
      EODIn
    • Conditions
      • Accounts =
        *
      • Times ≥
        23:30
  • Filter group 2
    • Name
      EODOut
    • Conditions
      • Accounts =
        *
      • Times ≤
        00:30
Trading will be disabled between 23:30 and 00:30.

Case 4

Preventing scalping trading
Rule:
  • Name
    Anti-scalping
  • Actions
    • Action type
      Reject
  • Filter
    • Request types
      Market
    • Entry type
      Out
  • Filter group 1
    • Name
      Scalpers
    • Conditions
      • Accounts =
        Scalpers-*
      • Duration <
        60
      • Profit <
        2
This rule prevents closing trades almost right after the opening which at the same time have low profit. Executing scalping strategies with a bit-by-bit profiting becomes impossible.

Case 5

Preventing opening too many positions on a particular symbol
Rule:
  • Name
    NotMoreThanTen
  • Actions
    • Action type
      Reject
  • Filter
    • Request types
      Market
    • Entry type
      In
  • Filter group 1
    • Name
      10pos
    • Conditions
      • Accounts =
        *
      • Symbols =
        EURUSD
      • Positions limit ≥
        10
This rule prevents opening more than 10 positions on the EURUSD symbol.

Applying a custom slippage

Case 1

Partial slippage compensation
Rule:
  • Name
    SlippageVIPCompensation
  • Actions
    • Action type
      Current price
    • Slippages
      • Negative action
        1
  • Filter group 1
    • Name
      VIP
    • Conditions
      • Accounts =
        VIP-*
Negative slippage will be compensated by 1 point for the VIP traders MetaTrader group.

Case 2

Adding a custom slippage
Rule:
  • Name
    AddSlippageToZero
  • Actions
    • Action type
      Current price
    • Slippages
      • Zero action
        = -5 -2 50%
A random custom negative slippage (from 2 to 5) will be added in 50% of cases for all the orders having a 0 natural slippage.

Delaying requests

Case 1

Delaying requests by 0.5-2 seconds during a high volatility period of EURUSD and opening trades at a worst price for traders:
Rule:
  • Name
    EURUSDDelay
  • Actions
    • Action type
      Worst Price
    • Delay
      500-2000
  • Filter
    • Time
      From: 2020.02.03 00:00:00; To: 2020.02.07 00:00:00
    • Request types
      Market
  • Filter group 1
    • Name
      EURUSDall
    • Conditions
      • Accounts =
        *
      • Symbols =
        EURUSD
Such a rule can be useful during high volatility periods of an instrument. According to the rule, all the EURUSD trades will be delayed by 2 seconds, and the worst price among the ticks that came in these 2 seconds will be picked. The rule is applied only for opening and closing a Market order.

Checking exposure before confirmation

Case 1

Preventing opening too much exposure on a particular security on a particular account.
Rule:
  • Name
    NotMoreThanTenThousand
  • Actions
    • Action type
      Reject
  • Filter
    • Request types
      Market
    • Entry type
      In
  • Filter group 1
    • Name
      10kusdcrypto
    • Conditions
      • Accounts =
        *
      • Symbols =
        Crypto\*
      • Exposure limit ≥
        Crypto\*; 10000; USD; Total; Include
This rule prevents opening crypto securities (on any account), if current exposure on them (including that of the requested order) is more than $10000 worth. Can be modified into:
Exposure limit ≥ *USD*; 10000; USD; Total; Include
to reject all crypto requests, if only USD-based crypto symbols exceed the allowed exposure (not taking into account, e.g., *EUR* crypto symbols). Or into:
Exposure limit ≥ *; 10000; USD; Total; Include; PerSymbol
to reject a crypto request, if the exposure on the requested symbol alone will exceed $10000, given the request is approved.
Case 1a
Using filter groups
The above mentioned subcases (slightly modified) can be placed into three separate filter groups in terms of one Reject rule to precisely control the allowed exposure on cryptos:
  • Filter group 1
    • Name
      5kusd_1crypto
    • Conditions
      • Accounts =
        *
      • Symbols =
        Crypto\*
      • Exposure limit ≥
        *; 5000; USD; Hedged; Include; PerSymbol
  • Filter group 2
    • Name
      7kusd_allusdcrypto
    • Conditions
      • Accounts =
        *
      • Symbols =
        Crypto\*
      • Exposure limit ≥
        *USD*; 7000; USD; Total; Include
  • Filter group 3
    • Name
      10kusd_allusdcrypto
    • Conditions
      • Accounts =
        *
      • Symbols =
        Crypto\*
      • Exposure limit ≥
        Crypto\*; 10000; USD; Total; Include
So, if the request is:
  1. Not increasing its crypto symbol exposure beyond $5000 level, and at the same time,
  2. Not increasing USD-based crypto exposure beyond $7000 level, and at the same time,
  3. Not increasing total crypto exposure by $10000 level,
it will not pass the rule’s filter tiers, and, according to our settings, it will get confirmed by the Default rule.
In these examples, exposure is checked per account issuing a request. Let’s see how Dealing Desk can check the total exposure on multiple accounts altogether.

Case 2

Preventing opening too much exposure on a particular symbol in a particular account scope.
Rule:
  • Name
    EURUSD Server limit
  • Actions
    • Action type
      Reject
  • Filter
    • Request types
      Market
    • Entry type
      In
  • Filter group 1
    • Name
      10musdbtc
    • Conditions
      • Accounts =
        USA*
      • Symbols =
        BTCUSD
      • Exposure limit ≥
        *; 1000000; USD; Total; Include; PerSymbol; AccountMask; USA*
This rule prevents opening a BTCUSD order, if it will make the BTCUSD exposure of all USA-groups altogether go beyond the $1,000,000 mark.
Case 2a
With a coverage account
The example above calculates total exposure of all groups in the scope per BTCUSD request. Imagine that the account scope is not just a bunch of groups, but the entire server:
Symbols = BTCUSD; Accounts = *; Exposure limit >= *; 1000000; USD; Total; Include; PerSymbol; AccountMask; *
Although Dealing Desk will calculate the exposure quite quickly, it will still do that per request, which has a risk of overloading the MT server, when requests are being sent frequently.
In this case, to drastically lower the possible load, it would be great to have a coverage account, which already has all BTCUSD trades of other accounts copied on it:
  • Account #101: Buy 1 BTCUSD, Buy 3 EURUSD
  • Account #102: Sell 2 BTCUSD, Buy 1 EURUSD
  • Account #103: Sell 1 EURGBP, Sell 3 BTCUSD
  • Coverage account: Account #100: Sell 4 BTCUSD (total BTCUSD of #101, #102, #103)
And the modified filters of the rule:
  • Conditions
    • Symbols =
      BTCUSD
    • Accounts =
      !100,*
    • Exposure limit ≥
      *; 1000000; USD; Total; Include; PerSymbol; AccountMask; 100
Now, while ending up with the same calculation results, Dealing Desk does this way faster, because it checks exposure of just one account #100 instead of checking the other three. This scheme can be scaled up to the entire server, saving lots of processing time for the plugin.
So, if you are planning to use Exposure limit for a similar case, you might want to pair it with a coverage account.

Limiting SL/TP levels of positions and pending orders

Case 1

  • Name
    NoHighSLTP
  • Actions
    • Action type
      Reject
  • Filter
    • Request types
      *
    • Entry type
      *
  • Filter group 1
    • Name
      SLTP
    • Conditions
      • Accounts =
        *
      • Stop deviation ≥
        sl:30%;tp:40%
Given the current price is 1.500, it will be possible to to set SL not higher than at the 1.500 + (-) 1.500*0.3 = 1950 (1050) levels, and TP - at the 2100 (900) levels.