Skip to content
Journal Archive
Featured image for The Expiry Was Wrong. The System Needs Changes. Rules Held. Trade Review

The Expiry Was Wrong. The System Needs Changes. Rules Held.

My Trading Desk

Two trades today. One loss in the opening phase – short PE, 27 minutes, clean. One win in late morning – short CE, held for 265 minutes. The longest hold I have ever recorded. But the rules journal note does not mention either trade. It says: “They messed up the Expiry. Need new changes in the mechanical system.” An external data failure – the expiry information was wrong – and the system noticed. The rules were followed. The trades were managed. But the system needs updating. This trading journal entry is about the day the system identified a defect and the operator scheduled a fix – all while the trades were still running.

This is the kind of day that used to produce a different outcome. In June, an external problem – broker rejection, data error, platform crash – would have triggered interference. I would have touched the trade, justified it as prudence, and regretted it later. Today the expiry was wrong. The system noted it. The operator noted it. The second trade was already in motion – a 265-minute hold that became the longest winning trade ever recorded in this journal. The data error was collected. The fix was scheduled. The trade was left alone. That is the difference between reacting to problems and absorbing them.

The Short Version

Quick Summary

  • Date: Tuesday 04 August 2026
  • Market: NIFTY – mixed intraday
  • Trades: 2 – 1 loss (27 min), 1 win (265 min – record)
  • Result: Mixed day
  • Discipline: 10.0 – rules followed
  • System: Expiry data error. Fix scheduled.
Key takeaway: External failures used to trigger interference. Now they trigger a system update note and a scheduled fix. The trade continues while the fix is prepared. That is how a mature system handles defects – acknowledge, absorb, update, continue.

The Trade Log

Two trades. Short PE in the opening phase lost in 27 minutes – the real trading problem was the usual one: level breaks not holding. The second trade was a short CE late morning that held for 265 minutes and closed at target. The move never really got going in a dramatic way but the follow-through was steady. Meanwhile, in the background, the expiry data was wrong. The system caught it. The note was written. The fix will happen after the session. The trade ran to completion.

What I Learned

There is a specific kind of maturity that shows up when something breaks and the system responds by scheduling a fix instead of triggering a reaction. The expiry data was wrong. That is a real problem – it could affect entries, exits, position management. But the problem was not an emergency. The trade was already managed by the plan. The fix could wait until after the session. The note simply recorded the defect and flagged it for correction.

This is the same system that survived three simultaneous failures in July. That day, the broker, system, and app all failed and the process still held. Today was a different kind of failure – data, not technology – and the response was the same: identify, record, schedule, continue. The system absorbs failures now. It does not react to them. The journal is the record of that absorption.

Risk Notes

Both trades stayed inside the predefined plan. The stop losses were respected. No interference despite the expiry data issue. The daily rules were followed. Discipline scored 10.0. The trade held for 265 minutes – the longest win on record.

Useful Resource

If this journal entry connects to one resource, it is the Bot Development page. A system that catches data errors, flags them for correction, and continues operating is exactly what custom automation should do. Identify the defect. Schedule the fix. Let the trade finish.

Related Reading

Simple Questions

What happened with the expiry?

The expiry data provided to the trading system was incorrect. This is an external data quality issue. The system flagged it. The operator noted it. A fix is being prepared. The trades were not affected because the plan does not depend on a single data source.

Why was the win not interrupted by the expiry issue?

Because the expiry error was a data problem, not a trade problem. The trade was managed by the plan – entry, stop loss, target. The data error did not change any of those parameters. The fix could wait until after the session. Separating trade management from system maintenance is a discipline that took months to build.

Final Note

One loss. One record-breaking win. One data defect. One scheduled fix.

The expiry was wrong. The system caught it. The trade continued. The rules held. The fix is on the list. That is how a mature system handles a Tuesday. The defect was noted without panic. The repair was scheduled without urgency. The trade completed without interference. That is three separate things going right at once, and two months ago none of them would have gone right.

Previous note
Next note