Skip to content

Build1 publisher3 min readPublished

A reassigned ticker sent a real order into Bath & Body Works instead of LandBridge

Yahoo's LB is LandBridge near $89. The broker's instrument list still had LB_US_EQ as Bath & Body Works near $19, and the only thing that closed the position was a stop loss the wrong stock was already far below.

The Engineer · Build desk

What happened

  • On 20 August a private trading system placed a real order for a company its owner had never heard of, because the screener and the broker resolved the same four letters to different companies.
  • Yahoo's LB is LandBridge at around $89, while the broker's LB_US_EQ was still Bath & Body Works at around $19, the name that company used before it became BBWI.
  • The exit loop closed the accidental position on its next pass only because $19 already sat below the $83 stop loss attached to the intended trade.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

  • cost A currency the system guessed rather than stored turns into a 100x sizing error that reaches the broker as a plausible order, so the account absorbs it before any exception surfaces.
  • exposure The same collision on an instrument trading above its stop leaves the portfolio holding a company nobody selected, with every later report and signal describing the wrong share.
  • constraint Because the gate fails closed on a fuzzy name match, the tradable universe is bounded by what the matcher can reconcile rather than by what the broker actually lists.
  • decision Missing earnings dates push whole markets out of entry scope and into watchlist-only status, which is a product boundary set by the data layer rather than the strategy.

The gate that now sits in front of the order runs on a name comparison rather than an identifier lookup. The resolver walks the broker's suffix list, builds a candidate ticker, checks it exists in the index, and if the broker's name for that candidate does not agree with the screener's name it prints a REFUSED line and returns None [8]. Names arrive dirty, so the comparison runs on token sets rather than strings, matching "Bath & Body Works Inc" against "Bath and Body Works", and it fails closed: no established match, no trade [9].

That is weaker than the principle it enforces. The write-up's one line of principle is that a symbol is a display label, not a primary key [7], and the clean implementation of that is a key both vendors publish. The only absences the piece records for the Yahoo chart endpoint are earnings dates and market cap [18], so nothing in it tells us whether either side exposes an ISIN or a FIGI. Two names and a fuzzy matcher were what was on hand, and the bill for that arrives on the other side of the gate.

The order itself was cheap for reasons that had nothing to do with design. The intended stock sat near $89 with a stop at $83, about 6.7 percent below the reference price [3]. The instrument that actually filled printed near $19, roughly 21 percent of the intended price and some 77 percent below the stop [4], so the exit loop had nothing to weigh and dumped it on the next pass [5]. The author's counterfactual is the load-bearing part: a wrong instrument trading above its stop is held indefinitely, with every subsequent analysis describing a different share [6].

The two silent failures are the better engineering lesson. The first resolver knew two suffixes, "_US_EQ" and "_EQ" [10], while the real constant carries eight [12], so six families of listing were invisible, including HUT as HUT_CA_EQ and 552 Canadian lines in total, dropped with no error, no warning and no log line [11][2]. This shrinkage happens quietly, with no page or alert sent when the tradable universe gets smaller. The second failure is arithmetic. London listings all sit behind the same l_EQ suffix, which contains five currencies, US dollars among them [13]. GBX is pence, GBP is pounds, they differ by exactly 100x, and 2,410 of one and 548 of the other sit behind those same four characters [14], which is 2,958 sterling-denominated lines a suffix cannot separate [1]. So currency is read once a day from the broker's instrument endpoint, stored next to the ticker, and fetched by sizing through currency_of() rather than inferred [15][16].

For this to be your problem, one condition suffices: a third party controls the string you join on, and your other vendor caches it. Both APIs worked as designed here; the ticker had been reassigned and the broker's instrument list still carried the old owner [4].

The same discipline shows in what the system declines to claim. The keyless chart endpoint returns daily open, high, low, close and volume with timestamps in one request, enough for moving averages, RSI and candle patterns [17], and no earnings dates at all [18]. Since the US flow refuses to open inside an earnings blackout, markets where that endpoint is the only source cannot be labelled entries; they go out as a watchlist, and the email says so [19]. The author also states up front that none of this made money and the strategy side is unsolved [20]. The transferable artefact is the plumbing, and the plumbing is most of the work.

What to watch

  • Whether the broker adds or renames instrument suffixes, since the list cannot be derived and has to be re-read from the dump.
  • Whether the keyless Yahoo chart endpoint keeps serving without a key, since the watchlist markets have no other source.
  • Whether the fail-closed name check starts refusing legitimate candidates often enough to justify paying for a shared identifier feed.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories