MT5 "Not enough money" (134/10019): 7 causas e soluções

ERR_NO_MONEY (MT5/MQL5): Solução Completa

Ao operar com um EA, ver ERR_NO_MONEY ou not enough money na aba Expert ou no Journal costuma causar pânico — "será que já estou sem fundos?" — mas, na prática, esse erro pode aparecer mesmo com saldo de sobra. A causa não é apenas "fundos zerados": há vários fatores, como cálculo de lote, alavancagem e margem retida por posições já abertas.

Este artigo é voltado tanto para quem usa EAs no MT5 quanto para quem programa EAs em MQL5, reunindo em um só lugar o que realmente é o ERR_NO_MONEY, suas 6 causas, soluções imediatas, cuidados específicos por corretora e prevenção definitiva no código. Para a lista completa de códigos de erro, consulte o Guia completo de códigos de erro do MQL5/MT5.

O que é ERR_NO_MONEY (diferença entre 134 e 10019)

Em MQL5, o valor que representa "fundos insuficientes" tem duas formas, dependendo de onde é obtido. Confundir isso atrasa a investigação da causa raiz.

① ERR_NO_MONEY = 134 (erro de runtime do GetLastError())

É o código de erro de runtime retornado por GetLastError(). O valor 134 é definido quando funções de cálculo como OrderCalcMargin() ou OrderCalcProfit(), ou código no estilo antigo, determinam que "a margem necessária excede a margem livre".

Significado: fundos insuficientes para a operação de trading (not enough money)
Constante: ERR_NO_MONEY
Valor    : 134

② TRADE_RETCODE_NO_MONEY = 10019 (código de retorno do OrderSend())

O resultado do envio efetivo de uma ordem via OrderSend() em MQL5 fica em MqlTradeResult.retcode. Quando a ordem é rejeitada pelo servidor por falta de fundos, o código não é 134, e sim 10019 (TRADE_RETCODE_NO_MONEY). Isso não é um erro do MT5 em si, mas sim uma notificação de rejeição vinda do servidor da corretora.

Significado: fundos insuficientes para concluir a solicitação (There is not enough money to complete the request)
Constante: TRADE_RETCODE_NO_MONEY
Valor    : 10019

// Exemplo típico de saída visível no log
2026.06.12 09:15:32.441 EA_NAME XAUUSD,H1: OrderSend error 10019

Na prática, como diferenciar:

Se o log mostra "134", o problema está na etapa de cálculo/verificação interna; se aparece "10019" ou o not enough money na aba Expert, é rejeição do servidor. Em ambos os casos, a causa raiz é a mesma (margem necessária > margem disponível), então a solução é comum aos dois.

Diagnóstico rápido em 30 segundos

Na aba "Toolbox → Trade" do MT5, verifique estes três valores.

Saldo (Balance)             : dinheiro na conta
Patrimônio (Equity)         : saldo ± lucro/prejuízo flutuante
Margem livre (Free Margin)  : margem disponível para novas operações ← o que importa aqui
Nível de margem (Margin Level %): Equity / Margin × 100

• Se a margem livre (Free Margin) for menor que a margem necessária para a próxima posição a abrir → o ERR_NO_MONEY é praticamente certo.
• Se o erro aparece mesmo com saldo suficiente, o motivo é um destes: "② lote excessivo", "④ margem retida por posições existentes" ou "⑥ tipo de conta diferente", explicados adiante.

A margem necessária para uma posição pode ser conferida em "Cotações → clique direito no símbolo → Especificação" no MT5 (margem de 1 lote). A fórmula aproximada é:

Margem necessária ≈ (Lote × Tamanho do contrato × Preço) / Alavancagem

Causas e soluções (6 padrões)

① Falta de margem, de fato

Sintoma: o prejuízo flutuante aumentou e a Free Margin ficou abaixo do necessário para uma nova posição. Comum após sequências de perdas ou em martingale com muitos níveis.

Solução:

1. Fazer um novo depósito, ou
2. Encerrar manualmente parte das posições abertas para liberar margem
3. Reduzir o RiskPercent do EA para diminuir o tamanho dos lotes futuros

Se esse padrão se repete com frequência, o lote está desproporcional ao capital disponível. Veja o item ②.

② Lote muito grande (em relação ao saldo)

Sintoma: há saldo disponível, mas o ERR_NO_MONEY já aparece na primeira ordem. Comum em operações com lote fixo.

Causa: o FixedLot não é compatível com o saldo/alavancagem da conta. Por exemplo, em uma conta de $670 tentando abrir 0.1 lote em XAUUSD, dependendo da alavancagem, a margem necessária pode superar o saldo.

Solução:

1. Reduzir o lote fixo para o mínimo (0.01) e verificar se a ordem é aceita
2. Migrar para cálculo automático por risco percentual (UseFixedLot=false / RiskPercent)
3. Se mesmo 0.01 não for aceito, o problema é alavancagem ou capital insuficiente → ver ③ e ⑥

③ Alavancagem baixa ou restrição em fim de semana/eventos

Sintoma: o mesmo EA e o mesmo lote funcionam em outra conta, mas só nesta conta dá ERR_NO_MONEY. Ou o erro se concentra entre sexta à noite e segunda de manhã.

Causa: quando a alavancagem da conta é baixa (ex.: conta regulada na UE em 1:30 vs. conta offshore em 1:1000), a margem necessária pode variar dezenas de vezes. Além disso, algumas corretoras reduzem a alavancagem nos finais de semana e ao redor de indicadores importantes (a XM, por exemplo, limita a alavancagem a 200:1 nos finais de semana), o que pode fazer a margem necessária aumentar repentinamente com a posição já aberta. Ouro e criptomoedas também podem ter limites de alavancagem específicos por símbolo.

Solução:

1. Verificar a alavancagem da conta (na área do cliente da corretora ou nas informações da conta no MT5)
2. Conferir a "taxa de margem" nas especificações do símbolo (pode ser mais baixa para determinados ativos)
3. Usar uma configuração que evite manter posições no fim de semana (CloseAllBeforeWeekend=true, por exemplo), ou migrar para uma corretora sem restrição de alavancagem no fim de semana
4. Trocar para uma conta com alavancagem mais alta ou reduzir o lote

④ Margem retida por posições existentes

Sintoma: a primeira posição abre normalmente, mas a segunda em diante — ou entradas adicionais (martingale) — resultam em ERR_NO_MONEY.

Causa: posições já abertas retêm margem, fazendo a Free Margin ficar abaixo do necessário para novas operações. É comum quando vários pares ou vários EAs operam na mesma conta.

Solução:

1. Verificar a margem em uso (Margin) e a Free Margin na aba "Trade"
2. Checar se EAs diferentes estão disputando margem na mesma conta (no caso de múltiplos EAs)
3. Limitar o número máximo de posições simultâneas via parâmetro do EA
4. Em EAs de martingale/grid, quanto mais níveis, mais rápido a margem é consumida → revisar limite de níveis, multiplicador de lote e configurações de fechamento de emergência

⑤ Bônus/crédito sendo contabilizado como margem

Sintoma: somando "saldo + bônus" o valor deveria ser suficiente, mas o ERR_NO_MONEY aparece mesmo assim.

Causa: em algumas corretoras, o crédito (bônus) não entra, ou entra apenas parcialmente, no cálculo de margem. Isso cria uma diferença entre o saldo exibido e a margem realmente considerada pelo servidor.

Solução: verificar nos termos de bônus da corretora se "o crédito é considerado na margem". Se não for, reduzir o lote para um valor compatível com a margem necessária usando apenas o valor efetivamente depositado.

⑥ Diferença de tamanho de contrato entre tipos de conta (padrão vs. cent/micro)

Sintoma: o mesmo "lote 0.01" funciona em uma conta e, ao trocar de conta, passa a dar ERR_NO_MONEY de repente — ou, ao contrário, resulta em exposição excessiva.

Causa: contas cent (micro) e contas padrão têm tamanho de contrato cerca de 100 vezes diferente. Um lote de 0.01 em conta cent representa uma exposição real de aproximadamente 1/100. Se o EA usa lote fixo sem diferenciar o tipo de conta, pode faltar margem em uma delas.

Solução:

1. Para operar com pouco capital e com segurança, usar uma conta cent/micro, garantindo que mesmo o lote mínimo não gere risco excessivo
2. Projetar o EA para não fixar o tipo de conta no código, e sim calcular o lote com base na margem real via OrderCalcMargin() (ver seção a seguir)

Cuidados específicos por corretora

Nas contas de alavancagem ilimitada da Exness (contas Pro/Raw Spread), novas ordens muitas vezes são aceitas mesmo com margem livre praticamente zero, o que torna esse erro raro. Isso combina bem com EAs de martingale, mas tem como contrapartida um Stop Out que quase não atua, elevando o risco de perdas maiores. Para comparar corretoras, veja também a página de comparação de corretoras.

Código em MQL5 para evitar esse erro (para desenvolvedores de EA)

Mais do que "corrigir", o design correto de um EA é evitar o ERR_NO_MONEY antes mesmo de enviar a ordem. O ponto-chave é: calcular a margem necessária antes de enviar a ordem e, se não houver margem suficiente, não abrir a posição ou reduzir o lote.

Verificar a margem necessária antes de enviar a ordem

// Gate pré-envio: confirma margem necessária <= margem livre antes de chamar OrderSend
bool HasEnoughMargin(ENUM_ORDER_TYPE type, double lots)
{
   double price = (type == ORDER_TYPE_BUY)
                  ? SymbolInfoDouble(_Symbol, SYMBOL_ASK)
                  : SymbolInfoDouble(_Symbol, SYMBOL_BID);

   double margin = 0.0;
   if(!OrderCalcMargin(type, _Symbol, lots, price, margin))
   {
      Print("OrderCalcMargin failed: ", GetLastError()); // 134, por exemplo
      return false;
   }
   double freeMargin = AccountInfoDouble(ACCOUNT_MARGIN_FREE);
   if(margin > freeMargin)
   {
      PrintFormat("Skip: need %.2f > free %.2f (ERR_NO_MONEY guard)", margin, freeMargin);
      return false;   // Não abre a posição = evita o ERR_NO_MONEY antecipadamente
   }
   return true;
}

Normalizar o lote para o mínimo/step permitido

Enviar diretamente o valor calculado por risco percentual, sem ajuste, pode não respeitar o lote mínimo ou o step de lote (a falta de normalização é uma causa clássica de rejeição de ordem). Em vez de desistir quando o lote calculado não é aceito, reduzi-lo para dentro do intervalo permitido ajuda a reduzir oportunidades perdidas.

double NormalizeLot(double lots)
{
   double minLot  = SymbolInfoDouble(_Symbol, SYMBOL_VOLUME_MIN);
   double maxLot  = SymbolInfoDouble(_Symbol, SYMBOL_VOLUME_MAX);
   double step    = SymbolInfoDouble(_Symbol, SYMBOL_VOLUME_STEP);
   lots = MathFloor(lots / step) * step;          // Arredonda para o step
   lots = MathMax(minLot, MathMin(maxLot, lots)); // Limita entre mínimo e máximo
   return NormalizeDouble(lots, 2);
}

Sempre verificar o retcode do OrderSend

Além do retorno booleano de OrderSend(), verifique result.retcode e trate especificamente o código 10019 (TRADE_RETCODE_NO_MONEY).

MqlTradeRequest req; MqlTradeResult res;
ZeroMemory(req); ZeroMemory(res);
// ... monta req ...
if(!OrderSend(req, res) || res.retcode != TRADE_RETCODE_DONE)
{
   if(res.retcode == TRADE_RETCODE_NO_MONEY)   // 10019
      Print("Not enough money. É necessário reduzir o lote ou depositar mais fundos.");
   else
      PrintFormat("OrderSend failed: retcode=%d, lastError=%d", res.retcode, GetLastError());
}

Parada de emergência pelo nível de margem

Adicionar uma trava de segurança que interrompa novas entradas (ou feche tudo) quando o nível de margem cair abaixo de um determinado percentual evita tanto a repetição do ERR_NO_MONEY quanto o colapso total da conta.

double level = AccountInfoDouble(ACCOUNT_MARGIN_LEVEL); // Nível de margem em %
if(level > 0 && level < EmergencyMarginLevel)          // Exemplo: 150%
{
   // Interrompe novas entradas e/ou encerra parte das posições, se necessário
}

Os EAs distribuídos pela FXEA365 implementam de forma padrão o "lote automático por risco %", a "verificação de margem antes do envio" e a "parada de emergência pelo nível de margem" (UseMarginEmergencyClose), permitindo operar sem sobressaltos mesmo com capital reduzido.

Checklist por prioridade

Conclusão

• O ERR_NO_MONEY tem duas faces — 134 (GetLastError) e 10019 (retcode do OrderSend = TRADE_RETCODE_NO_MONEY) — mas a causa raiz em ambos os casos é a mesma: "margem necessária > margem disponível".
• Mesmo com saldo disponível, o erro pode ocorrer por lote excessivo, alavancagem baixa (incluindo restrições de fim de semana), margem retida por posições existentes ou diferença no tipo de conta.
• Quem opera EAs deve prevenir usando "lote automático por risco %" e o "tipo de conta adequado"; quem desenvolve EAs deve implementar solução definitiva com "gate de OrderCalcMargin antes do envio", "normalização de lote" e "tratamento do retcode 10019".

Para a lista completa de códigos de erro, consulte o Guia completo de códigos de erro do MQL5/MT5; para EAs gratuitos projetados para operar com capital reduzido sem riscos excessivos, veja a lista de EAs. Se você já usa um EA deste site e o problema persiste mesmo após ajustar as configurações, entre em contato pelo formulário de suporte anexando um print da situação de margem da sua conta.

Perguntas frequentes

P: Tenho saldo suficiente, mas o ERR_NO_MONEY aparece mesmo assim. Por quê?

Porque a verificação é feita pela margem livre (Free Margin), não pelo saldo (Balance). Se prejuízo flutuante ou margem retida por posições existentes reduziu a Free Margin, não é possível abrir novas posições mesmo com saldo disponível. Confira a Free Margin na aba "Trade".

P: Qual a diferença entre 134 e 10019?

134 (ERR_NO_MONEY) é o erro de runtime retornado por GetLastError(); 10019 (TRADE_RETCODE_NO_MONEY) é o resultado (retcode) de OrderSend(). Eles diferem apenas em onde aparecem — a causa (fundos insuficientes) é a mesma.

P: O erro não aparece no backtest, mas ocorre ao vivo. Por quê?

Porque a alavancagem, o tipo de conta (cent/padrão) e as posições já existentes na conta real costumam ser diferentes das configurações usadas no teste. As diferenças de alavancagem e de tamanho de contrato têm impacto especialmente grande.

P: Em EAs de martingale/grid, o ERR_NO_MONEY aparece quando os níveis aumentam. É normal?

É o sinal de que o problema está prestes a acontecer. Quanto mais níveis, mais rápido a margem é consumida. Reduza o limite de níveis e o multiplicador de lote, sempre ative um fechamento de emergência como o UseMarginEmergencyClose, e opere apenas com capital que você pode se dar ao luxo de perder.

P: É possível evitar isso automaticamente pelo código do EA?

Sim. Basta calcular a margem necessária com OrderCalcMargin() antes de enviar a ordem e adicionar um gate que impede abrir a posição (ou reduz o lote) quando o valor ultrapassar AccountInfoDouble(ACCOUNT_MARGIN_FREE). Veja o exemplo de código no corpo do artigo.

P: Com quanto de capital dá para começar com segurança?

Uma conta padrão de $670 com lote mínimo de 0.01 é um patamar razoável para começar. Para operar com menos capital ou com mais segurança, uma conta cent (micro) reduz a exposição real mesmo no lote mínimo, tornando mais fácil evitar o ERR_NO_MONEY.