Your baseline is lying to you and it will liquidate your

I recently watched a piece of production code wipe out every open position on a live trading account and then refuse to execute a single trade for the rest of the day. The logic wasn't broken, and the market hadn't crashed. The culprit was a simple user action: the account owner moved some capital out of the account.

This is a classic case of a "silent baseline drift," a bug that crops up whenever you cache a reference point and then compare live state against it while an external actor modifies the underlying value out-of-band.

The logic error in plain C

The system was designed with a simple safety guard to prevent catastrophic daily losses. It captures the starting equity and compares it to the current equity:

double dayPnL = currentEquity - dayStartEquity;

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

On paper, this is perfectly fine. It measures the delta between the start of the day and now. However, it makes a massive, unstated assumption: that trading is the only thing that can move the currentEquity number.

The moment a withdrawal happens, currentEquity drops. If someone pulls out $500, dayPnL suddenly reads -$500. The code doesn't know the difference between a bad trade and a bank transfer; it just sees a massive drop in value and triggers the emergency liquidation. Conversely, a deposit looks like a massive profit spike, potentially hitting "take profit" targets that were never actually earned.

This isn't just a fintech problem. You'll see this in:

• Rate limiters that use a fixed start count but get reset administratively.
• Disk-usage monitors that baseline at boot, only to have a new volume mounted later.
• Progress bars calculating percentage against a total that grows dynamically.

Implementing a robust fix

You can't stop the underlying value from moving, so you have to detect the out-of-band change and manually adjust your baselines to maintain the integrity of your measurement.

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

dayStartEquity += shift;
peakEquity += shift;
initialBalance += shift;

In a real-world deployment, you need a way to identify these "non-trading" events. In this specific case, I had to scan the transaction history for specific record types:

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

By shifting the baseline by the exact amount of the transfer, the dayPnL remains an accurate reflection of trading performance, unaffected by the change in total capital.

Making the deployment production-ready

When you move from a theoretical fix to a real-world AI workflow or automated system, you need to consider efficiency and edge cases. Here is my hands-on guide for implementing this without killing your performance:

1. Trigger-based scanning: Don't scan the history on every single tick or loop iteration. That’s a massive waste of CPU. Only trigger the history scan when the account balance actually changes.
2. Bound your queries: If you are working with an account that has years of history, querying the entire database will lag your system. Since everything prior to "today" is already baked into your baseline, limit your scan strictly to the current day's records.
3. Disable in simulation: Backtesting environments don't have cash transfers. If you leave this logic active during a high-speed optimization run, you'll turn a 5-minute test into a 30-minute coffee break.

One final note on architectural discipline: I had to be careful not to over-correct. My first instinct was to fix every single function that read the balance. That would have been a mistake. Position sizing should react to the new balance—if you have half the money, you should risk half the amount. You only need to shift the risk baselines (the things measuring change over time), not the actual state of the capital itself.