"[261006] Fixing a Stock Classifier Misclassification and Correcting a Paper-Account Reconciliation Gap"

I found and fixed a bug that mistook actively-traded stocks for halted ones and kept blocking buys on them, then traced and corrected a reconciliation gap in a paper trading account.

This is the English version of a post originally written in Korean for my algorithmic trading system devlog(new tab).

Tracking down a classifier bug that was blocking buys

This morning I noticed a few stocks weren't getting bought as often as usual, and went looking for why.

The trading system has a separate classifier that filters out halted or delisted stocks. It turned out this classifier was misreading a few actively-traded stocks as "halted" and had been blocking buys on them continuously.

The root cause was a disclosure-text parsing error. Some disclosures said a trading halt was being "cancelled," but the cancellation wording wasn't recognized, so the halt status stuck around anyway.

There was also a case where a disclosure about a delisting-related agenda item got misread as an actual delisting. On top of that, I found a structural flaw: once a stock got classified as halted, there was no separate signal for when it got cleared, so it could stay stuck permanently.

I needed to figure out whether this was a policy issue or a plain bug, so I asked two different AIs for independent opinions. Both landed on the same conclusion: this was a data-interpretation bug, not a policy call.

To undo today's impact first, I applied a temporary patch that reopened buys on the misclassified stocks. Then in the evening I merged and shipped a proper fix to the parsing logic that caused the problem in the first place.

After shipping the fix, I re-scanned the full stock universe to check whether the same issue was hiding anywhere else.

Tracing a reconciliation gap in a paper account

Later that evening, a different problem showed up. The reconciliation residual on one paper trading account crossed its alert threshold, which automatically blocked new buys starting the next day.

Looking into it, the position quantities and valuations in the ledger matched the broker side exactly. The residual was coming almost entirely from cash.

The gap grew larger on days with more trading activity. That pointed to the fee rate baked into the ledger being set lower than the real rate, leaking a small amount of cash on every trade.

I couldn't fully confirm this since there was no way to inspect the fee breakdown directly on the paper server side. Still, I went ahead and applied an estimated fee rate to the ledger and made a one-time correction for the residual that had built up so far.

After applying it, I reran the reconciliation, confirmed the residual was back in a normal range, and restarted the process.

Why this matters

Both incidents today started from the same small signal: a number that didn't add up.

One was a data-interpretation bug, the other a cost-assumption error. Different in nature, but in both cases I traced the root cause fully before touching anything.

For the classifier, I only fixed it after getting a cross-check from independent AIs confirming "bug, not policy." For the reconciliation, I only corrected it after following the numbers until I was confident in the estimate.

What's next

I'll check tomorrow that the classifier fix carries over into the new snapshot, and that the stocks affected today keep reading as normal trades.

I'll also watch the paper account's reconciliation residual to make sure it stays in range starting from tomorrow's first round.