The overnight batch: pricing a whole book before the open

Every firm that runs separately managed accounts has a window. It opens when the previous session's prices, dividends, corporate actions, and cash movements have settled enough to be trusted, and it closes when the market opens and the orders have to be in. Inside that window, the firm has to do something deceptively simple to state and brutally hard to guarantee: look at every account, decide what it should hold today given everything that changed, and produce a set of trades that respects each account's constraints, taxes, and benchmark. Do it for one account and it is a pleasant afternoon's work. Do it for two hundred thousand accounts and it becomes the single hardest operational promise the firm makes, every single night.

Why deadlines don't behave like averages

The most expensive misconception in this whole domain is the idea that performance can be reasoned about with averages. "Our optimizer solves an account in about two seconds" is a comforting sentence that tells you almost nothing about whether the batch will finish. What finishes the batch is not the average case; it is the worst case, multiplied by the number of accounts, plus whatever variance the system introduces under load. A deadline is a hard constraint, and hard constraints are governed by tails, not means.

Consider what happens when a small fraction of accounts hit a hard instance — a tricky constraint set, an unusual concentration, a day where the market moved enough to make the problem genuinely difficult. If the optimizer occasionally takes thirty seconds instead of two, and that happens to even a few percent of a large book, the long pole in the tent stops being the typical account and becomes the pile of stragglers. The batch finishes when the last account finishes, and the last account is, by definition, the worst one. This is why teams that obsess over median latency are often blindsided by batches that fail: they optimized the part of the distribution that was never the problem.

The arithmetic of a growing book

Personalization makes this worse in a specific, quantifiable way. When you sold pooled funds, adding a client added assets but not problems — the same handful of models served everyone. When you sell personalized accounts, adding a client adds a problem. The batch workload is therefore proportional to the number of distinct accounts, and the number of distinct accounts is the very thing your sales team is paid to grow. A book that doubles in accounts doubles the nightly compute even if the assets per account stay flat, and it does so against a window that does not get any longer just because you got more successful.

There is a second, subtler multiplier hiding here. As personalization deepens — more constraints, more values screens, more household-level coordination, more tax-lot history to respect — each individual problem gets harder, not just more numerous. So the firm faces growth on two axes at once: more problems, and harder problems. Either alone is manageable. Together, on a fixed overnight window, they are how comfortable desks walk into a wall they did not see coming.

What actually relieves the constraint

There are only a few honest ways out, and most firms try them in the wrong order. The first instinct is to throw cores at the problem, which helps until the per-seat economics of a commercial solver license turn linear scaling into a budget conversation. The second instinct is to relax quality under deadline pressure — to let the optimizer return whatever it has when the clock runs out — which trades a visible failure for an invisible one, because now the accounts traded on a worse answer and nobody flagged it. The third instinct, hiring, simply moves the cost from the cluster to the org chart.

The durable answer is to attack the thing that actually binds: throughput per unit of cost, with predictable worst-case behavior and no license tax that punishes scale. A system that can hold its quality bar while clearing the whole book inside the window — and do it deterministically, so that the same inputs always produce the same trades and a compliance reviewer can re-derive any decision — turns the overnight batch from a recurring source of risk into a non-event. That is the whole goal: to make the most operationally dangerous hour of the day boring.

The firms that internalize this stop asking "how fast is your optimizer on a single account?" and start asking the only question that predicts whether they can grow: "can you clear my entire book, at my quality bar, inside my window, every night, without the cost curve bending up?" It is a less exciting question than the ones that get asked in investment committee, and it is the one that decides who can say yes to the next ten thousand accounts.