One account.
Three managers.

Advisors who want three mandates for one client get told to open three accounts. That is not an operational requirement. It is an assumption made in 1998.

The workaround everyone has agreed to stop noticing

An advisor decides a client should hold three mandates. A core equity manager, a fixed income specialist, and something satellite — a tax-aware overlay, a sector strategy, a legacy position managed on its own terms.

In a great many systems, the answer is to open three accounts.

Nobody presents this as a limitation. It is presented as how it is done, and it has been how it is done for long enough that a generation of advisors assumes it is an operational requirement rather than a software constraint. It is a software constraint. It comes from an assumption made early in the design of most portfolio systems: that an account holds one model.

What the workaround costs the client

Three custodial registrations produce three statements, and the client counts them. They now believe they have three portfolios, because they have three of everything that indicates a portfolio.

Cash sits in three places and is short in one of them. Tax lots fragment across registrations, so the loss you needed to harvest is in the account you were not looking at. The fee schedule reads as three relationships and has to be explained as one. Beneficiary designations get made three times, which means they get made inconsistently at least once.

And the annual review starts with ten minutes of reassembling into one story what the operational system split into three.

What it costs the advisor

Rebalancing stops being a decision and becomes a coordination problem. There is no single cash position to draw a distribution from, so a withdrawal request means three decisions about which sleeve of the client's wealth to sell — except they are not sleeves, they are registrations, so each one has its own settlement, its own trade date, and its own chance to go wrong.

Performance has to be stitched. Drift is measured three times against three targets, none of which is the client's actual asset allocation. And when the advisor wants to change managers, the change is a transfer rather than a reallocation.

The other design

The alternative is to make the mandate, not the registration, the unit of management.

One registration holds several managed allocations. Each one carries its own model, its own drift tolerance and its own trading instructions. Each is measured against its own benchmark and reported on its own terms. But there is one account, one statement, one cash position and one set of tax lots, and the household above it rolls up to a single number that is the client's actual portfolio.

Changing a manager becomes a reallocation inside the account rather than a transfer between accounts. A withdrawal draws against one cash position. The client sees one relationship, because they have one.

Assign it once, at the household

The same logic runs one level up. A decision about a client is a decision about the household, not a chore repeated per account.

Set the allocation at the household and it applies across the accounts underneath it — with the exceptions named explicitly, because there are always exceptions. The concentrated legacy position the client will not sell. The account under a threshold where trading it costs more than the drift. The security that is restricted for this family and no other.

Those exclusions are part of the assignment, recorded with it, rather than living in an advisor's memory and getting rediscovered the first time the household is rebalanced by somebody else.

The question that tells you which one you are buying

Most platforms will now tell you they support sleeves, because the word sells. The distinction that matters is whether sleeves exist at trade time or only at report time.

So ask it directly: are orders generated per sleeve, or generated for the account and then allocated back to sleeves afterwards?

The second one is a reporting overlay. It looks correct on a statement and it is a reasonable thing to build. But it means the trading logic still believes the account holds one model, and every place that belief surfaces — tax-lot selection, cash targets, restrictions, drift bands, the order in which managers get funded — is a place where the overlay has to be patched to look like something it is not.

You will find those patches eventually. Usually at the worst time, which is when a client asks why one manager was sold to fund another.

What we will not publish

We are not going to publish how allocations are held, how orders are constructed across mandates, or how the cascade resolves when a household-level decision meets an account-level exception. That is engineering, and it is ours.

The design principle is not proprietary and you should hold every platform to it. One registration. Many mandates. One number for the client.