Household Data Models for Wealth Management | The Toronto Group
Architecture Guide

Household Data Models for Wealth Management

How to architect Salesforce Financial Services Cloud to securely map complex, multi-generational wealth, trusts, and Centers of Influence.

The Executive Summary

Generic CRMs treat clients as isolated contacts. In wealth management, a client is rarely just an individual; they are part of a household, a beneficiary of a trust, and represented by external counsel. FSC's native Household Data Model allows firms to map these complex relational webs securely, ensuring accurate AUM roll-ups and regulatory compliance.

The Flaw of the "Flat" CRM Model

If you implement a standard B2B CRM (like Salesforce Sales Cloud) for a wealth management firm, the default data model forces you to create an "Account" (representing a business) and attach "Contacts" (representing employees) to it.

When applied to wealth management, this creates a structural nightmare. If a husband and wife each have individual RRSPs/IRAs, a joint margin account, and a family trust, a flat CRM cannot accurately aggregate their total Assets Under Management (AUM) without aggressive, brittle custom code. More importantly, it creates a regulatory blind spot for KYC and suitability requirements.

The Automation Ceiling

If your data architecture cannot natively link spouses, dependents, and trusts together into a single entity, you cannot automate compliance workflows or generate accurate portfolio performance reports.

The FSC Solution: Person Accounts & Households

Salesforce Financial Services Cloud (FSC) solves this by fundamentally altering the core object model. It introduces two mandatory concepts: Person Accounts and the Household Object.

1. The Person Account

A Person Account merges the standard Salesforce "Account" and "Contact" objects into a single, unified record representing a human being. This individual holds their own specific KYC data, risk tolerance, and communication preferences.

2. The Household Object

The Household is a custom record type that acts as a container. Person Accounts are attached to the Household. This architecture allows FSC to automatically "roll up" the financial accounts (AUM) of every individual in the household into a single, aggregate view for the advisor.

Smith Family Household (Total AUM: $4.2M)
Contains (Account Contact Relationship)
John Smith (Person Account)
Jane Smith (Person Account)
Owns
Owns
Individual IRA ($1.2M)
Corporate Account ($3.0M)

Mapping Centers of Influence (COIs)

High-net-worth clients do not operate in a vacuum. They rely on external CPAs, estate attorneys, and corporate executives. FSC manages this via Reciprocal Roles (Account-Contact Relationships and Contact-Contact Relationships).

Instead of just listing a CPA in a text field, FSC allows you to create a distinct Person Account for the CPA, and link them to multiple different client Households. When an advisor views the CPA's record, they can see exactly how much AUM that specific Center of Influence has referred to the firm.

// Example Reciprocal Role Configuration in FSC

Role: "Estate Attorney"
Inverse Role: "Client"
Association: Jane Smith (Household Member) <--> Robert Legal (External COI)

Result: Advisor gains 360-degree visibility into professional referral networks without duplicating contact records.

The Regulatory Impact

Architecting your data this way isn't just about making the advisor's dashboard look clean; it is a strict regulatory defense mechanism.

CIRO, SEC, and FINRA require that investment suitability be assessed comprehensively. If an advisor recommends a high-risk equity in Jane's individual account, the compliance officer must be able to view that trade within the context of the entire Smith Family Household's liquid net worth and aggregate risk tolerance. Flat CRMs make this nearly impossible to prove during an audit. FSC makes it native.

Migration & Implementation Warning

Because the FSC data model is strictly relational, you cannot simply "upload" legacy spreadsheet data into the system. Moving from a legacy CRM requires a complex ETL (Extract, Transform, Load) process. Data must be cleansed, transformed into Person Accounts, and programmatically linked to Household containers via API.

This data transformation phase is where generic Salesforce implementation partners fail. It requires dedicated FSC Data Architects who understand wealth management schemas.

Need Help Transforming Your Data?

Migrating legacy wealth data into FSC's Household model requires precision engineering. Schedule a Technical Discovery with our Data Architects to map your migration path safely.

← Back to Insights