Data models are not glamorous. They rarely feature in executive briefings or technology strategy decks. But in practice, the data model underneath your CRM is one of the most consequential decisions your organization makes — because everything else is built on top of it. How you represent a customer, how you model their accounts, how you track ownership and balance history: these architectural choices shape what is possible, what is painful, and what is simply out of reach.
The shift from the FSC managed package to FSC Core involves a set of data model changes that are, by any reasonable measure, significant. Some of them are genuinely transformative for banking and lending use cases. This post walks through the three most important changes — financial account ownership, balance history, and household modeling — and explains why they matter in plain terms, grounded in the kinds of scenarios your teams encounter every day.
We will save the household and Party Relationship Group changes for Post 4. This post focuses on financial accounts and balance architecture — the foundation on which everything else sits.
Change 1: How Account Ownership Is Modeled
The Managed Package Approach
In the FSC managed package, financial account ownership is driven by two lookup fields on the Financial Account object: Primary Owner and Joint Owner. One field points to the primary account holder. One field points to a secondary holder. That is the full extent of the model.
For simple retail banking scenarios — a single customer with a checking account, or a joint savings account held by two spouses — this works adequately. But the moment you move into more complex ownership structures, the limitations become tangible.
Consider a commercial lending scenario: a small business line of credit with three guarantors, a trust account with a corporate trustee and two beneficiaries, or a multi-borrower mortgage with four co-applicants. The two-field ownership model cannot represent these structures natively. Teams work around it with custom fields, related lists, and junction objects they build themselves — which adds complexity, creates maintenance overhead, and produces data that does not aggregate cleanly across the household or relationship group.
The FSC Core Approach
FSC Core replaces the Primary Owner and Joint Owner fields with a junction object called Financial Account Party. Instead of two fields on the financial account record, ownership is represented as a set of child records — each one a Financial Account Party linking an account to a party (person or entity) with a defined role.
This changes the ownership model from a hard constraint of two parties to an open, extensible structure that can represent any number of owners, guarantors, trustees, beneficiaries, or authorized users — each with their own role, start date, and relationship attributes.
The Financial Account Party junction object does not just remove a two-party ceiling. It transforms account ownership from a field into a relationship — one that can carry context, history, and complexity.
For banking and lending institutions, the practical implications are immediate:
- Multi-borrower loans can be modeled natively, with each borrower represented as a Financial Account Party with an appropriate role. No custom junction objects required.
- Trust accounts with corporate trustees and multiple beneficiaries can be represented with a single clean data structure.
- Business accounts with multiple authorized signatories, each with different access levels, can be modeled as distinct party relationships with distinct roles.
- Ownership history becomes possible — because ownership is a record rather than a field, you can track when parties were added, removed, or had their roles changed.
- Aggregation and reporting across all accounts associated with a party becomes cleaner, because the relationship is explicitly modeled rather than inferred from field lookups.
|
BANKING USE CASE: Commercial Lending A regional bank manages a $2.5M commercial real estate loan with a primary borrower, a co-borrower, and two guarantors. Under the managed package model, only the primary borrower and one joint owner can be represented natively on the loan account record. The guarantors require custom objects and manual reporting workarounds. Under FSC Core, all four parties are Financial Account Party records on the same loan account, each with a defined role (Primary Borrower, Co-Borrower, Guarantor). Relationship managers see the full ownership picture on a single record. Risk reporting can aggregate exposure across all parties automatically. No custom development required. |
Change 2: How Account Balances Are Stored
The Managed Package Approach
In the FSC managed package, each financial account has a single balance field. When the balance is updated — whether manually, through a nightly batch integration, or via a third-party data feed — the new balance overwrites the previous one. The prior balance is gone. There is no native history.
For institutions that need to show clients their account balance today, this is functional. For institutions that need to answer questions like “what was this account’s balance sixty days ago?” or “how has this portfolio changed over the past quarter?” or “what was the high-water mark on this lending facility in the past year?” — the managed package offers no native answer. Teams build custom history tracking, export to data warehouses, or maintain parallel reporting systems.
The FSC Core Approach
FSC Core introduces the Financial Account Balance object — a child object of Financial Account where balances are stored as individual records rather than overwriting a single field. Each balance record captures the balance amount, the effective date, the balance type, and the source of the update.
This seemingly simple change has significant downstream consequences. Balance history is now a first-class data structure within Salesforce. It can be reported on, visualized, aggregated, and analyzed without requiring a custom solution or an external system.
Moving balances from a field to a child object transforms your CRM from a snapshot tool into a longitudinal record of your client’s financial relationship with your institution.
The comparison between the two approaches is direct:
|
FSC Managed Package |
FSC Core (On-Platform) |
|
Single balance field — overwrites on update |
Financial Account Balance child records — history preserved |
|
No native balance history |
Full balance history queryable in Salesforce |
|
Trend reporting requires external systems or custom objects |
Trend reporting available natively via standard reports and dashboards |
|
Integration updates destroy prior data |
Integration updates append new balance records; history intact |
|
No balance type differentiation on single field |
Balance type (available, current, outstanding) captured per record |
For lending institutions in particular, the Financial Account Balance object is transformative. Loan account balance history — principal outstanding, accrued interest, available credit on revolving facilities — can now be tracked natively within the CRM. Relationship managers have the longitudinal view they need to have informed conversations with clients. Risk and compliance teams can run historical analysis without leaving Salesforce.
|
LENDING USE CASE: Revolving Credit Facility Monitoring A commercial bank relationship manager oversees a portfolio of revolving credit facilities. She needs to identify which clients are consistently utilizing more than 80% of their available credit — a signal of potential stress — over the past six months. Under the managed package, this analysis requires exporting data to a BI tool or building a custom history tracking mechanism. The CRM shows current balances only. Under FSC Core, Financial Account Balance records for each revolving facility provide a native six-month utilization history. A standard Salesforce report surfaces the at-risk accounts in minutes. No data export. No custom objects. No BI tool required for this use case. |
Change 3: Summary Rollups and Performance
The managed package’s rollup-by-lookup feature has long been a pain point for FSC implementations. It enables aggregation of financial account data up to the household or account level, but comes with well-documented constraints: a limited set of objects it can roll up from, performance issues with large data volumes, and a nightly batch processing model that means the data a relationship manager sees in the morning may already be hours out of date.
FSC Core addresses this with two mechanisms. First, Summary Rollups operate via the AccountFinancialSummary object, which aggregates balance data from Financial Account Balance records. The architecture is cleaner and more flexible than rollup-by-lookup, supporting criteria-based rollups across multiple objects.
Second, and more significantly, Salesforce is actively building toward on-demand real-time rollup capabilities in FSC Core. The Data Processing Engine templates that ship with Core today already represent a meaningful performance improvement over the managed package’s batch-only model. Real-time on-demand rollups — currently on the roadmap — will eliminate the staleness problem entirely for institutions that need live portfolio views.
For a retail banking institution managing daily balance changes across hundreds of thousands of accounts, or a lending institution where a relationship manager’s dashboard needs to reflect the current state of their portfolio, the difference between batch-nightly and real-time is not a technical footnote. It is the difference between a CRM that supports the actual rhythm of client conversations and one that routinely shows yesterday’s data.
What the Data Model Change Requires of You
It would be incomplete to describe these data model improvements without acknowledging what the transition requires. The FSC Core data model is not backward compatible with the managed package in every respect. Organizations moving from managed package to Core will need to plan for data migration — specifically around financial account ownership records, balance history, and the junction objects that replace field-based relationships.
This is not a reason to stay on the managed package. But it is a reason to approach the migration with a clear-eyed assessment of your current data structures and a realistic data migration plan. Post 9 in this series covers the migration framework in detail. The key point for now is that the data model differences are knowable, mappable, and manageable with the right approach.
Salesforce has published migration guidance specifically for the Financial Account object and the Groups and Households model. The ecosystem of FSC implementation partners has developed tooling and patterns to support the transition. The path is well-worn enough that institutions moving now are not pioneers — they are following a route that others have navigated before them.
The data model changes in FSC Core are not just technical improvements. They are a rethinking of how a CRM should represent the complexity of modern financial relationships — particularly in banking and lending, where ownership structures, balance dynamics, and relationship hierarchies rarely fit into simple two-field models.
Looking Ahead: Households and the Party Relationship Group
The financial account data model changes described in this post are one half of the data model story. The other half — equally significant for banking and lending institutions — involves how FSC Core models households and relationship groups. The shift from the managed package’s Household record type to the Party Relationship Group object is the subject of Post 4.
Together, the Financial Account Party model and the Party Relationship Group model represent a comprehensive rethinking of how Salesforce represents the full complexity of a financial institution’s client relationships. Understanding both is essential to understanding what FSC Core makes possible that the managed package cannot.
PREVIOUS IN THE SERIES
Post 2: What “On-Platform” Actually Means — Demystifying FSC Core for Financial Institutions
NEXT IN THE SERIES
Post 4: Households Reimagined — The Party Relationship Group and What It Means for Banking
