Exports one CSV line per closed trade with the numbers a statement does not carry: the best unrealised profit the trade showed (MFE), the worst unrealised loss it survived (MAE), how much of the MFE was actually kept, how many bars it spanned, and how long it was held. Same measurement as the Trade Excursion indicator, written to a file instead of drawn, because the questions worth asking of this data are ones a chart cannot answer: does the capture ratio depend on the hour of entry? Are the trades I close early the ones I hold longest? Do losers on Mondays reach a different MAE than on Fridays? Those are one pivot table away once the CSV exists. Output is semicolon separated with a header row, in MQL5\Files; opens in any spreadsheet. Measurement limit: excursions come from bar highs and lows on the chosen timeframe; the path inside a bar is unknown. The bars column reports the resolution each trade got, and the summary counts single-bar trades separately instead of averaging them in.

Your statement tells you what you KEPT. It does not tell you what you HAD. This indicator reads your own closed trades from the account history and draws, for each one, the full range it travelled: the best unrealised profit it ever showed (MFE) and the worst unrealised loss it survived (MAE). The gap between what a trade showed and what it paid is where two common problems hide, and neither is visible in a balance curve: winners closing far below their best point (the exit leaves money behind), and losers whose worst excursion barely passed the stop (the stop sits inside the noise). The number to look at is the CAPTURE RATIO: of the profit a winner showed at its best, how much did you take home? 90% says the exits are well placed; 30% says the market kept offering and the exit kept refusing. Limit, stated up front: excursions come from the bars each trade spanned, on the chart timeframe; the path inside a bar is unknown. Predicts nothing; measures trades that already happened.

A daily process writes "today's decision" (which strategy runs, or FLAT) to a file the EAs read at the open. One day the writer did not run. The EAs read yesterday's file, compared its date with TimeCurrent() - the server clock, which had stepped back to the previous day overnight - saw a match, and traded all morning on a 24-hour-old decision. No error anywhere. Two rules, both in this class: 1) staleness is judged against TimeLocal(), which always moves forward; TimeCurrent() is the last tick's stamp - it freezes without ticks and can step back on reconnect. 2) When in doubt the answer is FLAT: missing file, bad date, wrong day, empty line - every failure path returns "do nothing", and each is logged ONCE per state change, not on every tick and not never. File format: line 1 = ISO date, line 2 = decision string. The demo writes a fresh, a stale, a malformed, an empty and a missing file, and shows that only the first is allowed to trade.

Four EAs on the same symbol, each one honest on its own: each checks "do I have a position?" with its own magic number, sees none, and enters. On a demo account this reached 22 contracts on a symbol meant to carry 1, and a watchdog had to close 16 positions in one morning. The cap belongs at the door, not after the fact. ExposureCap::Allowed(symbol, lots, cap) sums the volume of every open position on the symbol - all magic numbers, manual trades included - and refuses the order BEFORE it is sent when it would breach the cap. One log line with the three numbers (held, requested, cap) says why. Deliberately simple: gross exposure, no netting of longs against shorts, no per-EA quota. It is a check, not a lock: two EAs deciding on the same tick can both pass; in practice EAs on different charts decide on different ticks. The demo script prints held / cap / room for the current symbol and shows the refusal line. Nothing is traded.

A datetime in MQL5 is seconds since 1970 - but server time (TimeCurrent, bar times, deal times) is the broker's wall clock stored AS IF it were UTC. Export it to CSV, read it in Python or a spreadsheet with a "seconds since 1970 UTC" parser, and every timestamp shifts by the server's UTC offset. On a UTC-3 broker that is three hours: the daily bar dated 00:00 reads as 21:00 of the previous day, and "yesterday's session" silently becomes "today's, half formed". That happened to a morning report of mine before this script existed. The script prints TimeTradeServer, TimeCurrent, TimeGMT and TimeLocal, the three offsets between them, the tick lag, and this chart's last bar time in server time and in real UTC - then states the rule: export server timestamps as wall-clock text, or export the epoch together with the offset, and never let the consumer apply its own timezone.