The Financial Account object is the centre of gravity in any Financial Services Cloud (FSC) implementation. Wealth management revolves around it. Retail banking layers on top of it. Mortgage and insurance attach to it in different shapes. Once an org settles on the Financial Account model, every downstream report, every advisor screen, and every integration takes its cue from those early decisions.
Getting the Financial Account model right on day one saves whole quarters later. Getting it wrong locks in patterns that cost engineering months to unwind.
What the Financial Account object actually is
In FSC, Financial Account is a standard object. It represents a single account that a client holds at a financial institution. The shape covers a deliberately broad set of cases. Bank current accounts, savings accounts, certificates of deposit, brokerage accounts, mutual fund holdings, mortgage liabilities, credit cards, and insurance policies all fit the Financial Account shape.
The shared object has its trade-offs. The schema is wider than any single account type needs. A current account does not care about asset allocation. A brokerage account does not need a credit limit. The Record Type system handles this: each type of account is a Record Type, and each Record Type carries the page layout that fits its semantics.
Standard fields that matter on every FSC implementation:
- Owner relationship. Each Financial Account has a Primary Owner, which is a lookup to Account (typically a Person Account). The relationship drives the household rollup chain.
- Type and subtype. The Record Type captures the broad category. Custom picklists subdivide further into specific product codes.
- Balance and currency. Numeric fields with currency metadata so reports can sum across multi-currency books.
- Open and close dates. Lifecycle markers; FSC uses these for active-account filtering on rollups.
- Status. Active, Frozen, Closed. The status field drives whether the account contributes to Household rollups.
The Asset object joins the model for orgs that track individual holdings inside a Financial Account. A brokerage Financial Account holds many Asset records, each representing one position in one security. The shape mirrors how a custodian system reports positions.
Standard record types and what they unlock
FSC ships a starter set of Financial Account Record Types. The standard ones include:
- Banking. Current accounts, savings accounts, time deposits.
- Investment. Brokerage, mutual funds, ETFs, managed portfolios.
- Mortgage. Home mortgages, refinances, equity lines.
- Credit Card. Revolving credit lines with credit limits.
- Insurance. Policy contracts with premiums and coverage details.
Each ships with the standard page layout, the standard rollup behaviour, and the standard related objects (Asset for Investment, Disbursement for Mortgage, Premium for Insurance). Implementations extend by adding custom fields and custom Record Types per product the bank actually offers.
The temptation to merge Record Types into one shared structure usually ends badly. A mortgage and a current account share almost nothing in their lifecycle, their reporting, or their compliance treatment. The Record Type split keeps these clean.
The holdings (Asset) sub-model
For investment accounts, the Asset object captures individual holdings. Each Asset record represents one position in one security, with fields for ticker or ISIN, quantity, current price, current value, cost basis, and asset class.
The shape supports both flat and hierarchical holdings:
- Flat. Each holding is one Asset row. Suitable for direct brokerage accounts.
- Hierarchical. A mutual-fund position is one Asset row; the underlying holdings inside the fund are not modelled. Suitable for managed-portfolio platforms.
Volume considerations dominate the holdings design. A retail wealth org with 50K HNW clients and an average of 30 positions per client produces 1.5M Asset rows. Multi-portfolio HNW orgs run into the 10M-plus range. At this volume, Asset queries need careful indexing on Financial Account and Asset Class, and full-table rollups need batch jobs rather than real-time RBL.
Where balances actually live
The most common first-time mistake on FSC is confusion about where balances live. Three layers stack:
The custodian system. The source of truth. Whatever core banking system, brokerage platform, or insurance admin system holds the actual balance. The Financial Account's Balance field in FSC is a cached view, not the source.
The Financial Account record. A snapshot of the custodian balance, refreshed on a defined cadence. Daily refresh is common; real-time is possible with platform events. The cadence depends on the integration architecture.
The rollups. The Household rollup, the Asset-class rollup, the segment-level reporting rollup. All derived from the Financial Account snapshot.
Implementations that confuse these layers end up with reports that disagree with the custodian system because the rollup is fresher than the snapshot or because the snapshot is fresher than the custodian. The right pattern is to define one canonical cadence and make every consumer aware of which freshness they are reading.
Integration patterns
The Financial Account record gets populated from the custodian system. Three common integration patterns:
Nightly batch. A daily ETL job pulls all account balances, computes deltas, and writes updates to FSC. Simple, predictable, lags by up to 24 hours. Suitable for wealth management where intraday accuracy is not critical.
Event-driven. Platform Events or Salesforce Connect external objects flow custodian changes into FSC in near real time. Higher integration complexity, lower lag. Suitable for active trading platforms.
Hybrid. Critical fields update in real time; less-critical fields update nightly. The Balance and Status fields might be event-driven; the Performance fields and Historical Yield fields might be batch. Most production wealth orgs converge on this pattern over time.
The integration shape should be decided before the data model is locked. Some FSC data-model choices (especially around hierarchical Asset records) are easier to change if the team knows the integration will or will not produce real-time updates.
Multi-currency, multi-jurisdiction shape
For banks operating across borders, FSC's multi-currency support is important. The Financial Account record carries a Currency ISO Code, and rollups can convert to a household-level reporting currency using the Salesforce Currency Conversion table.
The conversion rate cadence matters. A daily fixing rate is standard for wealth reporting. Real-time FX rates are possible but rarely necessary; clients see daily reports, not minute-by-minute valuations.
Jurisdictional shape lives in custom fields. A regulator-driven attribute like "Is Cross-Border Account" or "Source Country" is a custom field on Financial Account, populated from the custodian system or from a static mapping inside FSC. The compliance reporting later in the implementation chain depends on these being present and accurate.
Day-one verification
For an FSC implementation reaching first production Financial Account data:
- Record Types match the actual product set the bank offers.
- Page layouts per Record Type show the fields that matter for that product.
- Custom fields needed for compliance reporting (KYC status, AML risk, jurisdictional flags) exist before any production data lands.
- The integration shape is documented and the cadence is communicated to every downstream consumer.
- Sandbox data exercises at least one multi-currency household and one multi-Record-Type household.
Going live without these checks is the most common pattern for production-data quality issues in the first 3 months. The fixes after the fact are always slower than the verification upfront.
Designing the Financial Account model for an FSC rollout? Sapota's Salesforce team, certified on Financial Services Cloud Accredited Professional (AP-208), runs Financial Account architecture, integration design, and custodian-system integration on every FSC engagement. Get in touch ->
See our Salesforce service page for team and credentials.
