The baseline that quietly stopped meaning anything (and closed real trades)

Gary McLaughlin — Sun, 30 Aug 2026 06:51:28 +0000

Last week a program I wrote closed every open position on a live trading account and refused to do any more work for the rest of the day.

Nothing had gone wrong. The owner had moved some of their own money out of the account.

The bug turned out to be a shape I have written a dozen times in completely unrelated systems, so it is worth writing down.

The code

The program guards against losing too much in a day. It stores a baseline when the day starts and compares the current value against it:

double dayPnL = currentEquity - dayStartEquity;

if (dayPnL <= -dailyLossLimit) {
    closeEverything();
    stopForTheDay();
}

That is correct. It is also completely wrong, and both statements are true at the same time.

It is correct for the thing it was written to measure: money won or lost by trading. It is wrong the moment the underlying value can change for a reason that is not trading — someone withdrawing funds. Equity drops by 500. dayPnL reads -500. The guard concludes the day has gone catastrophically badly and liquidates positions that were doing nothing wrong.

A deposit produces the mirror image: the profit target is hit by money that was simply added.

The actual bug

The baseline and the measurement had silently stopped meaning the same thing.

dayStartEquity means what the account was worth before today's trading. currentEquity means what the account is worth now. Subtract them and you get today's trading result only if trading is the sole thing that can move the number.

Nobody wrote that assumption down. It was true when the code was written and it stayed true right up until it wasn't.

This is not a trading bug. It is the bug you get any time you cache a reference point and then compare live state against it, while some other actor can move the underlying value out of band. Rate limiters that store a start count and get reset administratively. Disk-usage alarms that baseline at boot and then someone mounts a volume. Progress bars that compute percentage against a total that changes.

The fix

You cannot stop the value moving. You can detect the out-of-band change and shift the baseline by the same amount, so the difference keeps measuring what you meant.

shift = detectOutOfBandChange();   // +500 deposit, -500 withdrawal

dayStartEquity  += shift;
peakEquity      += shift;
initialBalance  += shift;          // every baseline, not just the obvious one

In this case the platform books transfers as a distinct record type, so detection is a history scan for that type. Concretely:

long type = HistoryDealGetInteger(ticket, DEAL_TYPE);
if (type == DEAL_TYPE_BALANCE || type == DEAL_TYPE_CREDIT)
    sum += HistoryDealGetDouble(ticket, DEAL_PROFIT);

Shift the baselines and the measured result is unchanged by the transfer, which is the behaviour you wanted all along.

Three things that made it production-ready

Only look when something moved. Scanning history on every tick is wasteful. The balance only changes when a trade closes or a transfer lands, so that change is the trigger; otherwise skip the scan entirely.

Bound the scan. Querying the full account history gets slow on an old account. Anything before today is already baked into the baseline by definition, so the scan only ever covers the current day.

Turn it off in simulation. Backtests have no cash transfers, and a per-close history scan across thousands of records turns an optimisation run into a coffee break.

The part I nearly got wrong

My first instinct was to correct everything that reads the balance. That would have been a second bug.

Position sizing is a percentage of the balance. If half the account is withdrawn, the amount you can afford to risk genuinely should halve. That is not distortion, it is the correct response to having less money. Only the risk baselines needed shifting — the things measuring change over time. Anything measuring current capacity was already right.

Worth asking of any fix like this: which of these values is measuring change, and which is measuring state? Only the first kind needs the adjustment.

The one that will catch you

The program persists its baselines so a restart mid-day does not reset them. So: transfer money while it is stopped, start it again, and it faithfully restores a baseline from before the transfer — and trips instantly on a fix that is otherwise working perfectly.

Reconciliation has to happen on startup as well as during the run. I only found this by reasoning through the restart path, not by testing, which is its own small lesson.

Test it

Point the thing at a demo account, move a small amount of money out, and confirm the day's measured result does not budge.

Two minutes. I had never once run it, and neither, I suspect, has almost anyone shipping this category of software.

The MQL5 implementation is on GitHub under MIT if it is useful: mql5-balance-operations-guard. I write about building automated trading systems at goldscalpers.com.

DEV Community: Gary McLaughlin