The journal says the guard fired: it printed the line at 14:22, it closed the positions, it stood the account down for the day. The next morning the challenge is failed anyway, and the firm's dashboard shows a daily loss you never saw on your panel.
The journal is not wrong. It recorded an intention rather than an outcome. A daily-loss breaker comes down to a boolean and a number, and both of them can lie to you while every line of code behaves exactly as written. I have been caught by all three of the lies below. Here is what each one looks like and how to fix it, whether you write your own guard or buy one.
First, what you are measuring
Two decisions come before any of the failure modes.
Measure equity, not balance. Almost every firm evaluates the daily rule on equity, which means an open floating loss counts against you right now, not when you close it. A guard that watches balance sees nothing at all while a losing position runs.
Measure it against a snapshot of the day-start balance, anchored on the broker's day boundary rather than yours. TimeCurrent is server time. Your PC clock is not, and every deal in your history is stamped in the server's.
The daily loss is then one expression: the day-start balance minus current equity, over the day-start balance, as a percentage. That is the easy part. Now the three lies.
Lie one: the latch fires before the close confirms
The obvious implementation checks the loss, calls a flatten, and sets the tripped flag on the very next line. The flag is recorded as fact when it was only a request.
CTrade's PositionClose sends a request. A true return means the server accepted it, which is not the same as the position being gone. Requotes, off quotes, a busy trade context, a partial fill leaving a residual position, or one symbol in a multi-symbol account being outside its session: any of these leaves a position open while your flag says the account is flat.
And the moment you need to flatten is the moment the book is thinnest and the spread is widest, so this is not a rare edge case. It is the normal case for this function. Give the closing trade object real slippage room, because a zero-deviation close is the one most likely to come back rejected.
The fix is to latch on the account state, not on the request. After flattening, recount the positions in scope, and set the breaker only when that count reaches zero. If a close was rejected, nothing latches, and the next cycle tries again. A guard that has not finished its job should not be telling you it has.
Lie two: the latch stops the guard, but it does not stop anything else
Once the flag is set, the natural thing is to return early and go quiet. Nothing is watching any more.
This is fine on a manually traded account where the human is the only thing that opens trades. It is not fine on the account this tool exists for. A copied signal fires forty seconds later. A third-party EA that never heard of your breaker takes its next setup. The position that then rides the account through the hard limit is one your guard watched arrive and did nothing about, because as far as the code was concerned the day was already over.
A latch is a state, not an event. While it is set, hold the scope flat on every cycle: if anything is open past the reset grace window, close it again, then return. Same logic for a maximum-drawdown lockdown, which should latch harder than the daily breaker: the day rolls over, a max-DD lock should not.
Lie three: the limit is not the firm's limit
The first two lies are about the flag. This one is about the number, and it is the one that fails a challenge while the guard does everything correctly.
Your guard reads ACCOUNT_EQUITY out of your terminal. The firm reads its own risk engine. Those two agree most of the time and disagree in ordinary ways. A swap or commission posting lands on their books before it lands on yours. A floating position is priced off a feed that is close to your broker's and not identical to it. Either side can be read mid-update. Every one of those gaps is small. The threshold is not a range, it is a line, and a limit enforced to the last basis point is a limit you cross by rounding.
So the guard has to stop early on purpose. Take the published limit, subtract a buffer, enforce the smaller number.
That introduces the bug that made an early tester think the tool was broken on install. Set a tight custom limit of 1.0 percent, leave the buffer at 1.0 percent, and the effective limit is zero. The guard trips on attach, at no loss at all, and looks insane. It needs a floor: take the larger of the firm limit minus the buffer, and a small non-zero minimum such as five hundredths of a percent.
The buffer is not a fudge factor for a guard you do not trust. It is the acknowledgement that you are measuring one thing and being judged on another.
Summary
Latched on intent. The journal says flat and stood down. A rejected close is still open.
Latched and went quiet. Nothing in the log since the trip. A copier reopened after it.
Wrong number. Your panel reads minus 3.9 against a 4.0 limit. The firm has you at minus 4.05 and has already closed the account.
Three more that cost me time. Persist the flag and the day-start baseline in terminal global variables keyed by the account login and the server date, because OnDeinit and OnInit run on every timeframe change, input edit, template load, recompile and VPS reboot, and a plain boolean comes back false on an allowance that is already spent. I wrote that failure up in full when I released Risk Sentinel and will not repeat it here. Give a manual reset a grace window, otherwise the guard re-trips on the same tick and the reset button appears to do nothing. And drive the guard off a one-second timer as well as OnTick, because a guard that only wakes on ticks from its own chart symbol stops running the moment that symbol goes quiet, which on a thin instrument or a half-closed session is exactly when the rest of the account is still moving.
What none of this does
There is no concealment in it and no room for any. The firm sees your equity curve exactly as it is, and the only thing a guard tries to change is where on that curve the positions get closed, on your side of their threshold rather than past it. It does not survive a gap through your stop, and it cannot undo a breach the firm has already registered. The firm presets it ships with are representative starting values and not contract terms, so read them against your own account agreement before you rely on one.
The attached example is the minimum honest version of the pattern: it latches on the recounted position total, and it keeps holding the scope flat while the latch is set. It opens no trades and carries no signal.
No martingale. No grid. No averaging down.
I ship this as Prop Guardian TechnoTrader on the MQL5 Market at $49.
