Personalized, tax-aware portfolios across thousands of accounts — deterministic, auditable, and fast at fleet scale. Every account is its own problem; the promise is to re-solve all of them, correctly and on time, as a fleet. PRISM runs the batch and reports exactly how long it took, per percentile.
In plain English. Instead of buying one fund that tracks an index, each client owns the actual shares in their own account. That allows the portfolio to be tailored to them and their tax bill to be actively managed — but it means every client needs their own calculation, every night. This page is about doing that for tens of thousands of accounts at once, before the market opens. Unfamiliar words? See the glossary.
At fleet scale, "it works" isn't enough — you need to know the p50, p95, and p99 of the run, because the tail is what blows the window. PRISM treats it as a production engine: batches from a thousand accounts up to a full 500,000-account book, each with tax-lot handling and a full audit trail.
A personalized, tax-aware account is a genuinely better product and a genuinely harder thing to run, because each account is its own optimization problem — its own lots, restrictions, and tax situation — that has to be re-solved as the world changes. Sell it to thousands of clients and you've signed up to run thousands of those problems, correctly, on a schedule.
That makes it a fleet problem, not a single-portfolio one. The work grows with the number of accounts, not the dollars, and the thing that breaks the window isn't the average account — it's the tail. Which is why the run has to be measured the way production systems are: by percentile.
Each is manageable alone. Together — every account correct, the whole fleet on time, the tail bounded — is where most stacks hit a wall.
Every account is a distinct problem and the count grows faster than assets — the work scales with the number of problems, not the dollars.
An average latency hides the accounts that blow the window. You need p50, p95, and p99 to trust the batch will finish on time.
Lot-level holding periods and wash-sale windows mean the right trade depends on each account's history, not just today's prices.
You bring the book; PRISM returns per-account trades, tax-lot handling, an audit trail, and the latency report for the batch. The methods are proprietary; the interface is simple.
One engine, fleet scale, deterministic.
Measured on a single RTX 4000 Ada GPU — 500,000 accounts across a 1,000-name universe, every configuration passing the tracking-error quality gate. Comparators are referred to generically as conventional / standard solvers.
500,000 accounts optimized in ~134 s from cold on one GPU (~268 µs/account) — the full daily book, gate-passing quality.
A warm re-solve of the same 500,000-account book in ~63 s (~126 µs/account) — fast enough to re-run the book intraday.
Against a tuned 10-core parallel commercial/open-source deployment (~56–68 min for the same book, extrapolated), at matched solution quality.
Full latency reporting on every batch — the tail percentiles, not just an average that hides them.
Lot-level tax handling per account, with a content-hashed audit trail for the whole fleet run.
Same inputs, same trades — re-derivable for any audit or exam date across the entire book.
Move the sliders to your book, return, volatility, and tax rate to see the after-tax wealth a tax-loss-harvesting overlay can recover over time.
8-week paid pilot on your data — you get a benchmark report on your real problem and reference pricing for production. Batched to your scale, with full latency reporting and every losing case shown.
Start an 8-week paid pilot →Prefer a form? Request a pilot →