Trading on yesterday's prices

On 5 May 2026, a subcommittee of ICE Futures U.S.'s Business Conduct Committee settled a matter with DV Trading LLC, a US proprietary trading firm, for $40,000. The conduct dated to a single day, 29 October 2024, and it is a textbook example of an algorithm running off the rails. An automated trading system DV operated was using a stale data feed, and on that outdated view of the market it placed a series of non-bona fide orders in the November 2024 Crude Diff futures contract, orders the exchange's Self-Trade Prevention Functionality then cancelled because they were, in effect, the firm trying to trade with itself.

The detail that lifts this out of the ordinary is what happened after DV noticed. The firm tried to resolve the problem by pulling the system into a test environment and redeploying it, more than once. It did not work. The system continued generating numerous non-bona fide orders throughout the trading session. So this was not a split-second glitch that was over before anyone could react; it was a known malfunction that the firm could not switch off and let run for the rest of the day. ICE found that DV may have failed to diligently supervise its automated trading and to maintain supervisory systems reasonably designed to achieve compliance.

No customer was harmed, and DV settled without admitting or denying the findings. But the case is a compact tour of how trading algorithms actually break: bad inputs, self-trading, and a remediation process that could not contain a live malfunction. It pairs neatly with the wider enforcement record, where the modal algorithmic-trading case is precisely this, a proprietary firm, an automated system in a futures market, and a supervision failure. This piece uses DV to lay out the common ways algorithms fail, what the record shows about where these cases land, and how firms can test their own risk frameworks against these failure modes before an exchange does it for them.

ICE cited three rules. The substantive one, Rule 4.02(l)(1)(D), addresses non-bona fide orders, the orders the algorithm generated on its stale feed and that the exchange's self-trade prevention repeatedly cancelled. A non-bona fide order is one entered without genuine intent to trade with the market at large, and a system trying to cross against its own resting orders produces exactly that, the raw material of a wash trade. The exchange's automated safety net caught many of them, which is the only reason the episode reads as a control failure rather than a market event.

The other two rules are about supervision, and they are where the real finding sits. Rule 4.01(a) imposes a duty to diligently supervise, and it is explicit that "agent" includes any automated system that generates, submits or cancels messages without human intervention, so a firm owns what its algorithm does as surely as what its people do. Rule 4.01(b) requires each firm to establish, administer and enforce supervisory systems and procedures reasonably designed to achieve compliance. ICE concluded that DV may have fallen short of both: it did not catch or contain the malfunction, and its supervisory framework was not equipped to stop a system that had started behaving badly.

The scheme tags on the case name the two behaviours precisely: wash sales, from the self-crossing orders, and misuse of test environments, from the repeated redeployments through a test setup that did not fix the problem. Neither required any finding of intent to manipulate. DV settled on a neither-admit-nor-deny basis, and the exchange sanctioned the firm for the state of its controls, not for a scheme. In automated markets that is increasingly the point: a poorly governed algorithm is a violation in itself, because the machine will keep doing the wrong thing until a control stops it, and here no control did.

DV is valuable precisely because its failure was so mundane. It did not involve a clever manipulative scheme or an exotic bug; it involved bad data and a fix that did not fix anything. That is what most algorithmic incidents look like from the inside. The starting point here is the input layer: an algorithm is only ever as good as the data it reads, and a stale feed is one of the most common and most dangerous inputs of all. Prices move on; the algorithm does not know; it acts on a market that no longer exists. Feed a system yesterday's prices and it will trade with total confidence and total wrongness.

From there the failure took a recognisable shape. Acting on stale prices, the algorithm generated orders that crossed against the firm's own resting interest, self-trades, which are both a market-integrity problem and a classic symptom of a data or logic fault. What is striking, and instructive, is the response. DV detected the issue and tried to remediate it live, moving the system to a test environment and redeploying it repeatedly, but the malfunction persisted through the whole session. That is the failure mode that should worry risk managers most: not that an algorithm misbehaved, but that once it did, the firm had no clean, immediate way to stop it. A redeploy is not a kill switch, and trying to debug a live system in production while it keeps firing bad orders is close to the worst available option.

Step back from this one case and the enforcement record shows a consistent catalogue of ways trading algorithms go wrong. It is worth naming them plainly, because they recur across firms and venues.

The connective tissue, again, is governance rather than code. DV was not fined for having a data problem; feeds go stale, and every trading firm will meet that eventually. It was fined because nothing in its control framework caught the stale feed before it traded, nothing stopped the self-crossing orders except the exchange's own tooling, and nothing let the firm halt the malfunction cleanly once it started. The algorithm failed the way algorithms usually fail, and the controls that should have contained it were not there.

The controls that would have contained DV are well established, and the exchange rulebooks increasingly require them. Drawing on the control design RegLabs derives from this case, four stand out for any firm running automated strategies.

The second is a real kill switch, not a redeploy. DV's remediation failed because it tried to fix a live system on the fly. Firms need an authorised person or automated trigger that can instantly halt a strategy or the whole firm, tested regularly, with clear activation criteria. The rule of thumb the DV case teaches is blunt: the first response to a misbehaving algorithm is to stop it, then diagnose, never the reverse. Debugging in production while orders keep flowing is how a contained problem becomes a session-long one.

The third is pre-trade risk controls, including self-trade prevention of your own. Every order should pass a pre-trade engine enforcing size, rate, position and loss limits before it reaches the exchange, and the firm should run its own self-trade prevention rather than relying on the venue's as a backstop. That the exchange's tooling cancelled DV's self-crossing orders is fortunate, not a control: the firm should have caught them first, and pre-trade checks tuned for wash and self-trade patterns are what does that.

The fourth is real strong separation between test and production, and real-time behavioural monitoring. The repeated bouncing of the system between test and live points to blurred boundaries; test environments must be segregated, clearly labelled, and never a place you debug a production incident. And the whole episode should have been flagged in seconds by monitoring the algorithm's behaviour, order and cancel rates, self-trade patterns, deviation from expected activity, not left to run all session. Detection has to operate at the speed the algorithm does, because the machine will not slow down to wait for a human review.

DV is one entry in a large and active enforcement theme. Across the RegLabs record, algorithmic-trading governance failures account for more than 580 catalogued actions and over $6 billion in penalties, spread across the SEC, the CFTC, FINRA and, above all, the exchanges that police automated trading on their own venues. The DV fine is small in dollars, but its shape is central: a control breakdown around an automated system, resolved by the venue where it happened. It also rhymes with recent cases at other exchanges, where a single misconfigured parameter or a stale input produced disruption and a supervision finding, a reminder that this is a pattern, not a one-off.

Zoom into ICE specifically, and the DV profile is the house style. Across ICE's catalogued algorithmic-trading cases, the recurring findings are disruptive trading and spoofing, followed by failure to supervise, wash sales and, in DV's case, misuse of test environments, and the great majority involve futures, often in energy and commodities. Failure to supervise is again the costliest and most connective finding: whatever the algorithm did, the firm is sanctioned for not governing it. A proprietary firm, an automated system, a futures product and a supervision gap is not the exception at ICE. It is the template.

The strategic reading is that the fine is the least of it. A stale feed that produces self-trades is one bad session away from a genuine loss, a client harm or a market dislocation, and the same governance gaps that draw a $40,000 exchange fine, no feed check, no clean kill switch, no pre-trade self-trade prevention, are the ones that produce a far larger loss when the numbers are bigger. The firms that stay clear of both are the ones that treat their algorithms as supervised systems with validated inputs, hard pre-trade limits, real-time behavioural monitoring and a tested kill switch, and that prove those controls work against the specific ways algorithms fail rather than assuming they hold.