There is a moment that happens in financial institutions running the FSC managed package that most Salesforce teams have stopped noticing, because they have grown so accustomed to working around it. A relationship banker opens a client record first thing in the morning and sees account balances and household totals that reflect the state of the world as it existed yesterday — sometimes last night at 2 AM, sometimes the night before if the batch job failed or ran long.
They know this. They have adapted to it. They cross-reference the core banking system for anything time-sensitive. They remind clients that the numbers in the CRM are “as of last night.” They build workflows that account for the fact that their relationship management system and their operational banking system are always, to some degree, out of sync.
This adaptation is so normalized that many institutions have stopped thinking of it as a problem. It is just how Salesforce works with financial data. It is a fact of life.
It is not. It is a consequence of a specific architectural decision in the managed package — the rollup-by-lookup mechanism — and FSC Core’s Data Processing Engine replaces that decision with something fundamentally better. This post is about what that means, why it matters operationally for banking and lending institutions, and why the performance architecture of FSC Core is not a technical detail but a business-critical upgrade.
How It Works
The FSC managed package’s approach to aggregating financial data — rolling up account balances to households, summing loan exposures across relationship groups, calculating net worth across a client’s full portfolio — is built on a mechanism called rollup-by-lookup. In this model, configuration rules define which child records should be aggregated to which parent records, using lookup field relationships to connect them.
The rollup engine then processes those rules in a nightly batch job. Every night, during a scheduled processing window, the system traverses the configured lookup relationships, calculates the specified aggregations, and writes the results back to the parent records. When bankers arrive the next morning, they see the output of last night’s batch run.
The Architectural Constraints
This model has several structural limitations that compound as an institution’s data volume and relationship complexity grow:
A CRM that shows last night’s balances is not a relationship management tool. It is a historical reference system with a very short history.
|
The Real Cost of Stale Data Consider what batch rollup lag costs a banking or lending institution in concrete terms: A relationship manager prepares for a morning meeting using household balance data from the previous evening. The client made a large wire transfer at 4 PM yesterday. The relationship manager walks into the meeting with the wrong numbers. A credit analyst reviews a borrower’s total loan exposure before approving a new facility. A loan payoff was processed at 3 PM yesterday, reducing the borrower’s outstanding balance significantly. The analyst’s view shows the pre-payoff exposure, potentially affecting credit decisions. A portfolio manager running an early warning report for at-risk accounts receives results based on last night’s balances. Several accounts that crossed a threshold during the previous afternoon are not flagged until tonight’s batch run. The response window narrows by 24 hours. An operations team troubleshooting a data discrepancy between the CRM and core banking discovers that a batch rollup failed three nights ago. The impact of that failure has been silently propagating through dashboards and reports ever since. |
FSC Core replaces rollup-by-lookup with the Data Processing Engine (DPE) — a Salesforce-native framework for high-performance data transformation, aggregation, and calculation. The DPE is not a patch on top of the managed package’s batch architecture. It is a different approach to the problem, built for the performance and flexibility requirements of modern financial institutions.
What the DPE Does Differently
The Data Processing Engine processes data transformations using a template-based model. Administrators configure DPE templates that define the source data, the transformation logic, and the target output. Those templates can be executed on demand, on a schedule, or triggered by platform events — giving institutions control over when and how their aggregation calculations run.
Salesforce ships FSC Core with eight out-of-the-box DPE templates covering the most common financial data aggregation use cases: household balance rollups, financial account summaries, relationship group aggregations, and more. These templates give institutions a production-ready starting point that can be extended and customized without building from scratch.
Several characteristics make the DPE architecture meaningfully superior to rollup-by-lookup for banking and lending use cases:
|
Lending Operations: Intraday Exposure Monitoring |
|
A commercial lending team needs to monitor aggregate loan exposure for a portfolio of business borrowers throughout the business day. When a borrower’s total exposure crosses a threshold — due to a new draw on a line of credit, a loan modification, or a new facility approval — the credit team needs to know within hours, not the following morning. Managed Package: Exposure aggregations are calculated in a nightly batch. A draw processed at 2 PM is not reflected in the rollup until the following morning. The credit team’s exposure monitoring is always operating on yesterday’s picture. FSC Core with DPE: A DPE template is configured to recalculate borrower exposure aggregations when a new Financial Account Balance record is written by the core banking integration. A platform event triggers the DPE template execution. The credit team’s exposure view reflects the 2 PM draw within minutes. Early warning thresholds trigger accurately, and the response window is measured in hours rather than days. |
|
Retail Banking: Morning Meeting Preparation |
|
A regional retail bank has 120 relationship bankers who begin each day reviewing their top client relationships before branch opens. They rely on household balance summaries, recent account activity, and total relationship value figures in Salesforce to prepare for the day’s client conversations. Managed Package: Household rollup data is from last night’s batch run. Balances reflect the prior afternoon’s state at best. On nights when batch jobs ran long or failed, some household summaries may be days out of date. Relationship managers have learned to cross-check the core banking system for anything time-sensitive, doubling their preparation effort. FSC Core with DPE: DPE templates are scheduled to run at 11 PM and again at 5 AM, ensuring morning data is as fresh as possible before branch open. Event-triggered recalculation handles significant balance changes in near real-time during business hours. Relationship managers see household summaries that reflect last night’s closing balances plus any early morning transactions — meaningful, accurate context for every client conversation. |
|
Private Banking: Multi-Entity Portfolio Aggregation |
|
A private banking team manages relationships that span multiple entities per client — personal accounts, family trusts, business operating accounts, and investment portfolios. Relationship managers need to see the total assets under management, total loan exposure, and net relationship value across all entities for each client family. Managed Package: Multi-entity aggregation is not natively supported by rollup-by-lookup. Each entity’s rollup is calculated independently. Relationship managers must manually total figures across entities, or rely on custom Apex that is fragile and expensive to maintain. FSC Core with DPE: A DPE template is configured to aggregate across all Party Relationship Group members, spanning person accounts, trust accounts, and business accounts within the same family group. Total AUM, total loan exposure, and net relationship value are calculated as a single group-level summary. Relationship managers see the complete picture in one view, backed by a high-performance, maintainable aggregation framework. |
The table below summarizes the key differences across the dimensions that matter most for operational performance:
|
Dimension |
Managed Package Rollup-by-Lookup |
FSC Core Data Processing Engine |
|
Processing model |
Nightly batch — runs once per day during a fixed window |
On-demand execution — triggered by data events or scheduled as needed |
|
Object coverage |
Limited set of FSC objects; cannot rollup across all custom objects |
Broad object coverage across standard and custom objects with flexible configuration |
|
Multi-household |
Cannot aggregate across multiple households natively |
Criteria-based rollups across multiple Party Relationship Groups and objects |
|
Performance ceiling |
Degrades with large data volumes; nightly windows can overrun |
Designed for high-volume processing; 8 out-of-the-box DPE templates to start |
|
Real-time capability |
No — always batch; most recent data is from last night’s run |
On-demand real-time rollups on roadmap; intraday refresh available today |
|
UI components |
Legacy Lightning components with limited configurability |
New Lightning Web Components (LWC) for both record and summary rollups |
|
Integration impact |
Integrations must work around batch timing; balance updates wait for next run |
Integrations trigger rollup refresh; balance changes surface in near real-time |
|
Transparency |
Difficult to diagnose rollup failures or staleness without custom logging |
Improved visibility into DPE job status, execution history, and data lineage |
One dimension of the DPE architecture that deserves specific attention for banking and lending institutions is its impact on integration design — specifically, how data flows from core banking systems, loan origination platforms, and other operational systems into Salesforce.
In the managed package world, integration architects designing core banking data feeds had to work around the nightly batch window. Data could be pushed to Salesforce throughout the day, but the aggregated views that relationship managers and analysts relied on would not reflect those updates until the next morning. This created a mental model in which Salesforce was not a real-time operational tool but a nightly snapshot system — useful for relationship context, but not reliable for current financial data.
The DPE changes this integration design calculus. When a balance update triggers a DPE recalculation, the integrated data becomes immediately visible in aggregated views. Integration architects can design data feeds that write Financial Account Balance records as transactions are processed, and the DPE handles the aggregation logic without custom Apex, without manual rollup triggers, and without waiting for a batch window.
For institutions that have invested significantly in core banking integrations built around the managed package’s batch model, this represents a meaningful re-architecture opportunity — one that yields better data freshness, simpler integration logic, and a more accurate real-time picture for every user in the system.
The Data Processing Engine does not just make rollups faster. It changes the fundamental relationship between Salesforce and your operational banking data.
It is worth acknowledging where the DPE stands today versus where Salesforce is taking it. As of the current FSC Core release cycle, the DPE delivers substantially better performance than rollup-by-lookup — with on-demand execution, broader object coverage, higher volume capacity, and event-driven triggering. Full real-time, on-demand rollup calculations are on the product roadmap and not yet generally available as a fully released capability for all use cases.
For institutions evaluating the transition to FSC Core, this means the performance improvement is significant and real today, with further improvement coming. The eight out-of-the-box DPE templates provide an immediate foundation. Event-driven recalculation covers the most operationally important use cases. And the roadmap trajectory is clearly toward eliminating the batch lag problem entirely.
Institutions that migrate to FSC Core now position themselves to adopt real-time rollup capabilities as they become available — without a subsequent architectural migration. Those that remain on the managed package will continue to operate with nightly batch limitations and will face a larger transition when real-time data freshness becomes a competitive requirement rather than a nice-to-have.
The question is not whether financial institutions will eventually need real-time financial data in their relationship management systems. They will. The question is whether your institution will be positioned to deliver it when that moment arrives.
PREVIOUS IN THE SERIES
Post 4: Households Reimagined — The Party Relationship Group and What It Means for Banking
NEXT IN THE SERIES
Post 6: Unlocking Agentforce and AI for Financial Services — Why Core Is the Required Foundation
About This Series
“Building the Future of Financial Services on Salesforce’s Native Platform” is a 10-part thought leadership series exploring why FSC Core represents the strategic imperative for financial services and banking institutions on Salesforce. Posts publish weekly.