Tax Aware Portfolio Rebalancing Software Problems: The 7 That Cost Clients Real Money, and How to Avoid Them

Why does the wash sale check get built at account level so often?

Because that is where the trade is. A developer building a rebalancer thinks in accounts, since an account is what holds positions, receives a trade file and reports to a custodian. Checking that account's own purchase history in a thirty day window is the obvious implementation, it passes every test somebody writes, and it is wrong in exactly the cases that matter.

The rule operates on the taxpayer, not the account. That means the check has to see accounts you do not trade and will never send an order to, including retirement accounts, a spouse's accounts where they are part of the same tax household, and accounts held at a different custodian. It also has to see the future, because a recurring contribution scheduled for next Tuesday and a dividend reinvestment due next week are purchases that will fall inside the window of a loss you are about to realise today.

The fix is a household level purchase calendar rather than a lookup. Every linked account contributes to it, including observed only accounts, and it carries scheduled future activity alongside settled history. The constraint is then applied in both directions in time before a sell order is generated, and the optimiser is told which loss harvest opportunities are unavailable rather than discovering it afterwards. This is unglamorous plumbing and it is the single clearest line between a system that is tax aware and one that says it is. Ask any prospective developer how they would prevent a wash sale caused by a reinvestment in a retirement account you do not trade. If the answer does not include a household purchase calendar with scheduled activity, they will build you an account level checker and you will keep the problem.

What goes wrong with custodian lot and cost basis data?

Firms consistently underestimate this and it is where timelines slip. Position data is straightforward. Lot data is not.

Lots arrive with gaps. Transferred in positions frequently carry no basis at all, or carry a basis the receiving custodian marked as unknown, or carry one that was reported months after the transfer and quietly restated. Corporate actions rewrite lots in ways that are correct at the custodian and unrecognisable to a naive importer. Wash sale adjustments already applied by the custodian change basis and holding period on lots you thought you understood. Gifted and inherited positions carry basis rules that no import routine infers on its own.

The consequence is that an optimiser confidently selects a lot to sell based on a basis figure that is a placeholder, and the realised gain the client sees is not the one the trade blotter promised. That is not a rounding error to an advisor sitting in front of a client.

The fix has three parts. Reconcile lots daily rather than at import, and treat a lot count or basis mismatch against the custodian as a hard exception. Carry a data quality flag on every lot, and exclude accounts with unresolved lot issues from automated trade generation entirely, routing them to a human queue instead. And plan the first release around a single custodian and taxable accounts only, because retirement accounts have no tax constraint and are the easy case. Proving the hard case first is the correct order, even though it feels slower.

Why do custodian trade files and execution feeds break after launch?

Because each custodian is a different product with a different definition of failure, and the failure that hurts is the silent one.

Trade file formats change on the custodian's schedule, not yours. A new field, a changed length, a tightened validation rule, and a file that previously loaded gets partially rejected. Rejection semantics differ: one custodian rejects the whole file, another rejects the offending lines and processes the rest, which means a rebalance can be half executed with nobody aware.

Execution feeds break on timing. A partial fill, a cancelled order, an order that executed at a different lot allocation than requested, or a trade that settled the next day and therefore reports on a different file. If the system assumes a released trade equals a completed trade, drift accumulates between what the platform believes the client holds and what they actually hold, and the next rebalance is computed on a fiction.

The fix is to treat every released order as an open item until execution is confirmed and reconciled at lot level, with an ageing view showing anything unconfirmed beyond a threshold. Alert on missing acknowledgements rather than only on rejections. And when a firm adds a custodian, price it as real weeks of work: file formats, position reporting quirks and rejection behaviour are three separate problems and none of them is a configuration change.

What happens when the audit trail and constraint reasoning are not covered?

The first serious question a regulator or a client asks is why this account traded differently from the model. A system that cannot answer that turns an ordinary review into an exercise in reconstruction.

Two records are needed and both get cut from first releases. The first is an immutable record of what was released, by whom, and what the account looked like when the decision was made, including every override with a reason attached. Storing the trade list is not enough, because the trade list does not show what was rejected or why an advisor changed it.

The second is the binding constraint. Real accounts carry restrictions: no employer stock, hold this bond to maturity, keep a defined sum liquid for a property purchase, do not exceed a concentration limit, transition this legacy portfolio within an annual realised gain budget. The interesting cases are conflicts, where the model wants to sell, the gain budget says no, and the drift policy says drift must be corrected. Something gives, and the system has to name which constraint bound and why. An advisor who can tell a client the portfolio is off model because correcting it this year would have cost a specific amount in tax is having a conversation. An advisor holding an unexplained trade list is having an argument.

Should you build custom or configure what you already own?

Do not build if most of your client assets sit in tax deferred accounts, because the entire premise disappears: realised gains, holding periods and wash sales do not apply inside them. Do not build under a few hundred accounts, where an advisor reviewing a rebalance manually is genuinely feasible and cheaper. And do not build if you already run Orion Eclipse or Envestnet and your process fits their hierarchy without side spreadsheets, because you would be paying to reproduce something you have.

Configure harder first. Orion Eclipse has real lot awareness, Smartleaf is built around tax management specifically, LifeYield focuses on asset location across a household, and 55ip built its name on tax aware transitions. Vestmark and Envestnet run at genuine scale for large sponsors. If your dissatisfaction is a missing report or an awkward workflow, that is a configuration and training problem, not a platform problem.

The build case appears when your investment process does not fit the tool's hierarchy: how a sleeve relates to a model, how a household aggregates, where a restriction lives, how a cash need interrupts a rebalance. The tell is the spreadsheet your operations lead maintains for the parts that will not bend. Build also when you serve multiple custodians and each one is a manual step, or when you are a turnkey asset management program whose rebalancing engine is effectively your product rather than a tool you consume.

How do hidden costs get into the quote?

Five items, each usually a single line.

Custodian count. The one firms underestimate most. Each additional custodian brings its own file formats, position reporting quirks and rejection semantics, and it is weeks rather than a setting. Ask for a named estimate per custodian.

Direct indexing style harvesting. Harvesting across hundreds of individual securities changes both the size of the optimisation and the data you need to feed it. It is a different project from model based rebalancing, not an extension.

Options and concentrated stock. These need their own handling and their own constraint logic, and a single line in a proposal never covers them.

Multi year transition planning. Modelling future tax years rather than the current one is a materially larger piece of work than most quotes allow.

The constraint hierarchy discovery. Most firms have never written down what happens when the drift policy and the gain budget disagree, and answering that question is a workstream with your investment committee, not a developer task.

What separates a build that works from one that fails here?

Trade generation happens at lot level, with the lot selection method specified per account and the tax impact computed and shown before release. A firm trading at position level and letting the custodian apply a default method is making a tax decision by accident in every account, every day, and the client finds out the following January.

The optimisation has a stated objective and a ranked constraint set, and it names the binding constraint per account. If a developer describes the logic as a sequence of conditional statements, you are getting a rules script rather than an optimiser. It will produce defensible trades right up until two constraints disagree, which is the only situation where the software was supposed to earn its cost.

The first release is deliberately narrow: your largest custodian, your main models, taxable accounts only, with a reviewable blotter and human release. Retirement accounts and additional custodians come later. Firms that start broad spend the first six months reconciling data and never reach the tax logic that justified the project.

And ownership is settled before kickoff: the repository, the cloud accounts and the unrestricted right to hire another firm. If the engine is what turns your models into client outcomes, it is a core asset rather than a utility, and a vendor holding it holds your process. At Digital Heroes the client owns the code from the first commit, and a firm that hedges on that question at proposal stage will not improve later.