How leading wealth platforms let advisors group related clients, and what our two source documents already decide about accounts.
A household is one of two things, and you have to pick which before anything else makes sense. It is either a relationship group — who is related to whom, and who may service them — or an account-aggregation group — which accounts roll up for reporting and fees. The best platforms carry both, but lead with one. Wove’s PRD leads with the relationship group and auto-derives the aggregation behind it; that hybrid is precisely what Salesforce Financial Services Cloud and Orion do together.
On the question that keeps surfacing — what happens to the accounts when I add existing clients? — every serious platform agrees, and so do our own two documents: you group people who already own accounts; you do not recreate the accounts. Existing accounts follow the client into the household automatically; you only open a new account when a member doesn’t have one yet, and that is a separate flow. Section 04 lays out the evidence.
Two capabilities separate best-in-class from the rest and are currently gaps for Wove: auto-suggested households (proposed from shared surname/address) and fee householding (aggregating balances to reach lower fee breakpoints). Both are treated as core elsewhere. Conversely, Wove’s “grouping is not permission” stance is exactly where the banking-grade platforms have landed — an area where lighter CRMs are weaker.
The creation experience is downstream of the model. Choose the model, and the entry points, roles, rollups and permissions follow.
| Model | What it is | Who leads with it |
|---|---|---|
| Relationship group | A container grouping people and their accounts for servicing, reporting, fees and permissions. “Who is related, and who can service them.” | Salesforce FSC · Wealthbox · Redtail · Practifi · eMoney · banking party models |
| Account-aggregation group | A grouping of accounts / entities for consolidated performance, AUM and billing. “Which accounts roll up.” | Addepar · Orion · SS&C Black Diamond · Envestnet Tamarac |
Wove sits in the first model — a relationship group — but creating one auto-spawns a locked Nexus consolidation for the second. The relationship is the master; the consolidation is derived.
This is answered the same way by the benchmark and by our own two source documents. The create-household step has no accounts field on purpose.
“Account creation is independent and not within the Household.”Ravi Chadda · PRD review comment #13
The system gathers the accounts the household’s members already own and consolidates them automatically — you never re-attach them.
“Once a household is created — a Nexus Portfolio (Account consolidation) will be created and exposed in the Household UI… Scope of Account valuations is the Household Parties that have an owner role on accounts.”PRD FR-11 · Ravi comments #5 & #15
The advisor then curates: “An advisor can exclude any of these accounts and add them back in” (comment #16). The linking flow even “confirms account visibility impact” on save (PRD §7, Flow 1) — it shows which accounts will surface, filtered by entitlements; it does not create them.
For household-first onboarding, or any member without a relevant account, you open an account through a distinct flow (board story H-5.2). The relationship pre-fills the account type.
“Relations — useful for information purpose & creating accounts with default relations (Joint / JISA / Trust).”Ravi Chadda · PRD review comment #12
Hard rule reinforcing that accounts pre-exist and are linked, not born in the household: “Exec code for the Household should be the same as the underlying linked accounts” (comment #2).
| You include… | Accounts behaviour |
|---|---|
| An existing client | Their existing accounts auto-appear in the household’s consolidated view — by ownership, entitlement-filtered. Nothing to add. |
| A new member / no account yet | You open an account afterwards via the separate flow; the relation pre-fills the type. |
| Either | Advisor can include / exclude any underlying account from the rollup. |
This is a universal pattern, not a Wove choice: across FSC, Addepar, Orion and Tamarac, the create flow is “add existing entities/contacts/accounts into a group” — accounts stay owned by the individual client/entity and are linked, never recreated. Addepar goes furthest, modelling ownership as graph edges with percentage look-through — the right reference for Alpheya’s UHNW trust and holding-company structures.
| Two entry points | A guided “New household” wizard and creation in-context (from a relationship graph or a client/CRM record). They almost always coexist. |
| Group, don’t recreate | Existing clients bring their accounts; you add existing entities into a group. (See §04.) |
| Standard-ish roles | Head/primary, spouse, dependent, trustee, beneficiary, POA recur — but bidirectional relationships (FSC) vs simple labels (CRMs) differ. |
| Fee householding | First-class and commercial — but only on billing platforms (Orion, Tamarac). CRMs and planning tools don’t do it. |
| Grouping ≠ access | FSC (Compliant Data Sharing) and banking platforms (entitlement APIs) grant record access separately, often gated on documented consent. |
| UMH convergence | Orion, SEI and Envestnet are all moving the household from a reporting/billing unit toward the primary unit of portfolio management. |
Our create flow matches FSC and the banking-grade party models. The account-population behaviour (§04) is already correct in the documents.
Our explicit-entitlement stance mirrors Avaloq/Temenos and FSC’s Compliant Data Sharing — and is stronger than lighter CRMs where householding often widens visibility. Well suited to MENA/UK data-protection needs.
Addepar’s percentage look-through ownership (not a flat member list) is the right model for UHNW trusts and holding companies — relevant to the PRD’s open question on Organisations as members.
Best-in-class propose households from shared surname/address to cut manual creation. We create fully manually. (Note: even the CRMs’ auto-suggest is unverified — so a modest, evidence-based version is a genuine differentiator.)
Treated as core by US wealthtech (Orion, Tamarac) with real revenue mechanics. Our PRD defers fees (H-8.2). Worth a conscious decision, not a silent omission.
The household is becoming the unit of portfolio management, not just reporting. Our locked-Nexus-consolidation is a first step; the strategic question is whether Wove follows the UMH curve.