Asymmetry Computing builds PRISM, a real-time optimization engine for institutional finance, and the workload it was built for has an awkward name: deadline-bounded institutional rebalancing. The phrase is a mouthful, but it describes something very concrete, and the reason it is hard is not the reason most people assume.
Here is the setup. A firm runs a book of accounts — hundreds, thousands, sometimes tens of thousands. Each account has its own holdings, its own cost basis, its own restrictions. Every night, or every time the market moves enough to matter, each of those accounts needs new target weights. Those weights have to respect a budget, a turnover limit, exposure bounds, exclusion lists, and tax-aware controls on which lots may be sold. And all of it has to be finished before trading can begin.
That last clause is the whole problem.
A deadline is a different constraint from a preference
Most optimization is discussed as though speed is a nice-to-have: the faster solver is better, the slower one is acceptable. That framing quietly assumes the answer is still useful when it arrives late.
In rebalancing, it isn't. If the book is not priced when the market opens, the trades do not happen. An optimal set of weights delivered forty minutes into the session is not a slightly worse outcome than one delivered on time — it is a different, worse business process, involving stale prices, manual triage, and a risk desk making judgment calls it should not have to make. The deadline is not a preference on the objective. It is a hard constraint on the workflow, and it sits outside the optimization problem where the solver cannot see it.
Figure 1: What the deadline actually bounds
Why the batch is the unit that matters
Rebalancing is usually described one account at a time, because that is how it is easiest to explain. But nobody operates one account. They operate the book, against a single shared deadline, and the book has three properties that a per-account description does not capture:
The workload is batched, not streamed. All the accounts need answers within the same window. There is no smoothing — the peak is the workload.
Tails govern, not averages. A batch finishes when its slowest member finishes. A solver with an excellent median and an occasional pathological case is worse, operationally, than a slower solver with a tight distribution. This is why per-percentile latency reporting — p50, p95, p99 — is the only honest way to describe batch performance, and why a single average number should be treated with suspicion.
Failure is not free. An account that does not return a feasible answer does not simply get skipped. Someone has to notice, decide, and act, inside the same shrinking window. A method that is fast but occasionally infeasible transfers its cost to a human at the worst possible moment.
Tax-awareness makes it worse in a specific way
Layer in tax and the problem changes character. Now the decision is not only which positions to hold, but which tax lots to sell, subject to wash-sale rules and holding-period effects. The constraint set stops being a clean geometric region and starts encoding accounting rules with sharp edges.
This matters for the deadline because it removes the easy escape hatch. Faced with time pressure, the natural move is to simplify the problem — loosen constraints, coarsen the universe, use a heuristic screen. In a taxable book, those simplifications have a price measured in real money left on the table, and it does not show up in the runtime column. It shows up in the client's after-tax return, months later, where nobody attributes it to the solver.
The trap: the two obvious ways out both fail. Exact methods produce excellent answers but stop responding within the window at book scale. Simple heuristics always return on time but give up after-tax value quietly. The interesting engineering lives between those failures.
What "good" looks like under a deadline
Once you accept the deadline as a hard constraint, the specification for an engine changes. It stops being "produce the optimum" and becomes something closer to a contract:
Return a feasible answer inside the window, every time. Feasibility under the time bound is the primary deliverable; near-optimality is what makes it worth having.
Make the result reproducible. The same inputs must produce the same outputs, and the run must be replayable later. In a regulated workflow, "we cannot reproduce what the system did last Tuesday" is a finding, not an inconvenience.
Make it auditable. Compliance needs to see why a trade was proposed, not just that it was. An audit trail is part of the output, not a logging afterthought.
Report the tail. Publish p95 and p99, not just the median, and say what happens on the cases that miss.
That set of properties — deterministic feasibility inside a time bound, with an auditable trail — is a genuinely different target from the one most optimization benchmarks measure. It is also, for what it's worth, the thing that decides whether a personalized-portfolio business can actually grow its account count without growing its operations team at the same rate.
Where to look next
The formal treatment of this workload, with a measured evaluation, is in arXiv:2606.23367, Asymmetry PRISM: A CPU/GPU Portfolio Optimization Engine for Deadline-Bounded Institutional Rebalancing. The evaluation artifacts behind it are public at github.com/AsymmetryComputing/prism-public-evaluation. A plain-language walkthrough of how that benchmark was constructed is in Inside the Asymmetry PRISM Benchmark, and the measured results are on benchmarks. If you want the same idea applied to a much shorter deadline, the grid-dispatch case is in Optimizing Grid Dispatch Inside the Control Tick.
Sources & further reading. Asymmetry Computing publishes the evidence behind PRISM openly: the paper Asymmetry PRISM: A CPU/GPU Portfolio Optimization Engine for Deadline-Bounded Institutional Rebalancing (arXiv:2606.23367), the public evaluation artifacts at github.com/AsymmetryComputing, the measured runs on benchmarks, and the provenance of every headline number on the research page.