USD to Russian

Could u explain what is 'Number of pairs' exactly? It's not clear.

Just that, the number of pairs that the EA is applied too.

What happens at the start of your EA when u have few open positions, won't the calculation give very large lot sizes?

BTW - make sure u check for Div/0 problems (for example make sure NumOfPairs != 0 before divide).

No, the size is usually around .3 at the most. NOP = 0 is handled outside this funciton. Thanks for the suggestion.

Oh, I c u r dividing by margin required... Haven't noticed that before.

You want amount at risk to be a fraction of the account size. But the amount at risk is really a function of open price(bid or ask) vs the initial stop, times the currency change per tick. That last part is complicated if the second half of the Symbol isn't in your account currency. This is my method:

//+------------------------------------------------------------------+
//| Lot size computation.                                            |
//+------------------------------------------------------------------+
double  LotSize(double SL_points, bool modifying = false) {
    /* This function computes the lot size for a trade.
     * Explicit inputs are SL relative to bid/ask (E.G. SL=30*points,) and if
     * returned lot size will be used in a new order or be used to modify an
     * pending order (trade count-1.) Implicit inputs are the MM mode, the MM
     * multiplier and currently filled or pending trade count (used to reduce
     * available balance.) Mode, multiplier, adjusted account balance determined
     * the maximum dollar risk allowed. StopLoss determines the maximum dollar
     * risk possible per lot. Lots=maxRisk/maxRiskPerLot
     **************************************************************************/
    double  ab  = AccountBalance();
    switch(MMMode_F0M1G2) {
    case MMMODE_FIXED:
        atRisk  = MMMultplier;
        break;
    case MMMODE_MODERATE:
        // See https://www.mql5.com/en/articles/1526 Fallacies, Part 1: Money
        // Management is Secondary and Not Very Important.
        atRisk  = MathSqrt(MMMultplier * ab)/ab;    // % used/trade ~const.
        atRisk  = MathSqrt(MMMultplier * ab
                            * MathPow( 1 - atRisk, OrdersTotal()-modifying ));
        break;
    case MMMODE_GEOMETRICAL:
        atRisk  = MMMultplier * ab
                            * MathPow(1 - MMMultplier, OrdersTotal()-modifying);
        break;
    }
    double  maxLossPerLot   = SL_points/Point
                            * MarketInfo( Symbol(), MODE_TICKVALUE );
    // IBFX demo/mini       EURUSD TICKVALUE=0.1 MAXLOT=50 LOTSIZE=10,000
    // In tester I had a sale: open=1.35883 close=1.35736 (0.00147)
    // gain$=97.32/6.62 lots/147 points=$0.10/point or $1.00/pip.
    // IBFX demo/standard   EURUSD TICKVALUE=1.0 MAXLOT=50 LOTSIZE=100,000
    //                                  $1.00/point or $10.00/pip.
    double  LotStep = MarketInfo( Symbol(), MODE_LOTSTEP ),
    // atRisk / maxLossPerLot = number of lots wanted. Must be rounded/truncated
    // to nearest lotStep size.
    //
    // However, the broker doesn't care about the atRisk/account balance. They
    // care about margin. margin used=lots used*marginPerLot and that must be
    // less than free margin available.
    marginFree   = AccountFreeMargin(),                     // Free Margin
    marginPerLot = MarketInfo( Symbol(), MODE_MARGINREQUIRED ),
    // So I use, the lesser of either.

    // I don't use MODE_MAXLOT as OpenNow handles that.
    size =  MathFloor(  MathMin ( marginFree / marginPerLot
                                , atRisk     / maxLossPerLot )
                        / LotStep )*LotStep;        // truncate
    if (size < MarketInfo( Symbol(), MODE_MINLOT )) {
        // Multiple orders -> no free margin -> LotSize(SL=4.1)=0
        // [risk=9.48USD/40.80, margin=10.62/1334.48, MMM=1x1, coat=0]
        //       0.23                  0.007
        Print(
            "LotSize(SL=", DoubleToStr(SL_points/pips2dbl, Digits.pips), ")=",
            size, " [risk=",    atRisk, AccountCurrency(),  "/", maxLossPerLot,
                    ", margin=",    marginFree,             "/", marginPerLot,
                    ", MMM=",       MMMode_F0M1G2,          "x", MMMultplier,
                    ", coat=",      OrdersTotal(),  // Count Of active trades
                "]" );
        return(0.0);    // Risk limit.
    }
    atRisk  = size * maxLossPerLot; // Export for Comment()
    return(size);
}   // LotSize

Thank you, it does sound complex and would not fit into my system very well beased on the lack of stop loss in my system or rather that stop loss is optional.

I just want to know if the current code I am using could possibly jump the lot sizes simply because it is being run in another country like russia instead of USA. It's odd, because I have my products in several countries only 3 russians have approached me about this issue.

Just a thought - margin required calculation depends on deposit currency... Maybe that has to do with it.

That sounds like it has to be the answer. Everything else in the equation is basically a constant, so an increase in the lot size must be corresponding to an increase in the free margin.

The trouble is that, as gordon is implying, the lot sizing isn't taking into account the deposit currency. Let's take an example where you've got lot sizing predicated in USD. If free margin is $3,000 then the other parameters (3, 6, 0.3) seem to lead to lot sizing of 0.5. However, let's then take the extreme example where the client has an equivalent yen-based account, where $3,000 would be something like Y270,000 (i.e. a USDJPY exchange rate of 90). You'd feed in free margin of 270,000 and get a lot size out of the equation of 45.0. This isn't factoring in that the tick-value on, say, EURUSD is $10 on a USD account, but Y900 on a JPY account.

Ok, now this is starting to make sense. However, the issue was that the starting balance was 3000, regardless of whether it was US currency or other he did not specify. But even in your JPN example, we have not reached a 1.0 lot size or greater that our client experienced. In addition, we have korean, chinese, japanese, and many other countries in our client collection, but still they are not experiencing this issue, it is only these few clients from Russia.

Ok, I have seen enough to expect a variance, but not one so large as this, my assumption is going to be that in order to have a trade of that size, it had to be something different than what was in the configuration or the code.

Thank you guys for your analysis, I appreciate your efforts.