A pricing and risk calculation at the center of the OM2 trading platform had started taking more than 30 seconds under load. The system still produced an answer, but on a short-duration trading platform the market kept moving while it calculated: prices changed, the broker’s exposure changed, and traders continued acting. The calculation existed to help the platform respond to those conditions. Quant’s analysis suggested that most of its economic usefulness sat much closer to the two-second range, deteriorated rapidly after that, and was largely gone by roughly eight seconds. They could see material economic effects in differences as small as 200 milliseconds. Thirty seconds was therefore more than a performance problem. The platform was reacting outside the window in which the reaction was meant to help.
The pricing mechanism combined current market movement with statistical information, time to expiration and the broker’s existing exposure to influence the prices offered to traders. Its value depended not only on the quality of the calculation but on whether it reflected conditions that were still current when the price was offered.
Some of the pressure came from coordinated trading behavior. We used group trading as a broad term for accounts acting in recognizable patterns, although coordination itself was not automatically treated as abusive. Known legitimate groups could be whitelisted, while other patterns were monitored more closely.
For this particular problem, timing was the important part. Some sophisticated groups were consistently good at finding short-lived opportunities in market movements. When our pricing response lagged, they had more time to act before the platform adjusted to the newer conditions.
Trading volume was increasing at the same time, adding load to the calculation. The result was an uncomfortable product dynamic: the mechanism became slower precisely under the kinds of market conditions in which reacting quickly carried the greatest economic value.
“Faster” wasn’t a product target
A calculation taking more than 30 seconds clearly needed attention, but the number alone did not tell us what success should look like. Moving from 30 seconds to 15 would be a substantial technical improvement. Five seconds would be better again. Neither number tells a product team whether further optimization is worth the engineering cost.
The economic analysis supplied the missing boundary. Around the two-second range, the pricing response was much closer to operating while the conditions behind the calculation were still actionable. As latency increased beyond that range, the mechanism lost effectiveness quickly.
That turned an open-ended optimization problem into a product decision. We could prioritize the work because we understood the business consequence, give Engineering a meaningful range to design toward, and define success without treating every additional millisecond as equally valuable.
The objective became specific: bring the pricing response back inside the period in which it could still influence the broker’s exposure.
The target created another constraint
Performance could not be improved independently of the behavior of the mechanism itself. The calculation influenced pricing and exposure, so a faster implementation that changed the underlying risk behavior would have traded one problem for another. Engineering therefore had to improve a complicated and sensitive component while QA exercised difficult pricing and market scenarios around the change.
The target had two dimensions from the outset: reduce the response time enough to get back inside the useful window, and preserve confidence in the behavior once it got there. This is where attaching a product outcome to the performance target was particularly useful. The team was not optimizing a number in isolation; the number represented a capability whose correctness and timing both affected the same business result.
Back inside the useful window
After release, calculation time was usually around two seconds or less rather than more than 30 seconds. Quant continued watching the same trader behavior and broker economics that had exposed the problem. Several coordinated groups that had previously been consistently profitable against the broker moved materially in the other direction. For one prominent group, the losses recorded after the change reached close to a million dollars.
A live trading environment cannot isolate variables the way a controlled experiment can; markets, exposure and trader behavior continued changing throughout the period. Even with that limitation, the movement was consistent with the original hypothesis: reducing the delay allowed the pricing mechanism to respond while more of the underlying market opportunity was still actionable. The strongest part of the result was therefore not one P&L number in isolation. The same chain held from beginning to end: trader economics exposed the problem, the economics defined a timing boundary, the boundary became a product target, and the post-release behavior moved in the expected direction after the system returned to that range.
The product boundary was time
Zero latency was never the objective. The useful target was the point at which the calculation could still affect the situation it was responding to. Once we understood that boundary, performance became much easier to reason about as a product investment. It had a business consequence, a stopping condition and a way to evaluate whether the technical improvement had restored the capability we actually cared about.
For this part of the platform, a few hundred milliseconds were not just an infrastructure measurement. Another 200 milliseconds had a P&L.