If your institution runs Salesforce Financial Services Cloud, you have probably heard the phrase “FSC Core” appearing more frequently in conversations with Salesforce, in implementation partner briefings, and in the wider community of FSC practitioners. You may have a sense that it matters — that something significant is shifting in the FSC landscape — but be uncertain about what exactly is changing, why it changes the calculus for your institution, and what you should be doing about it.
This series is written for you.
Over ten posts, published weekly, we will make the complete case for why FSC Core represents the most consequential platform decision facing Salesforce-based financial services institutions today. Not as a product pitch, but as a genuine examination of the architecture, the capabilities, the compliance implications, the integration landscape, and the migration realities that every institution running FSC on the managed package needs to understand.
We will be specific. We will use real banking and lending scenarios. We will be honest about what is hard and what is not. And we will give you the information you need to assess your institution’s position and make a well-informed decision about the path forward.
This series is not about convincing you that change is inevitable. It is about giving you the clarity to choose when and how to lead it.
Salesforce launched the Financial Services Cloud managed package in 2016. For years, it was the foundation of FSC — the technology layer that gave Salesforce its financial services identity, with specialised objects for household management, financial accounts, and relationship banking built on top of the core Salesforce platform.
Starting around 2019, Salesforce began a quiet but significant rebuild. The goal: move FSC off the managed package architecture and onto the native Salesforce standard object model. The result, now several years into development and increasingly mature, is what is known as FSC Core — a version of Financial Services Cloud where the financial data lives not in a publisher-controlled managed package with its own namespace, but in standard Salesforce objects that are fully accessible to the entire Salesforce innovation stack.
The managed package is not being deprecated tomorrow. But it is no longer where Salesforce is investing. Every significant new capability — Agentforce agents that can reason about financial relationships, Data Cloud profiles that unify banking and CRM data, real-time rollup performance through the Data Processing Engine, open banking API integrations that connect fintechs and data providers directly to financial account data — is being built for FSC Core. The managed package is receiving maintenance. FSC Core is receiving the future.
The gap between what institutions on the managed package can access and what institutions on FSC Core can access is widening with every release cycle. That is the urgency behind this series.
This series is written for a mixed audience — deliberately so. The decision to migrate from the managed package to FSC Core is not a purely technical decision, and the case for it is not a purely technical argument. It requires alignment across technology leaders, business leaders, compliance teams, and the Salesforce practitioners who will actually execute the migration.
Different posts speak more directly to different audiences. The table below is a rough guide to where each reader might want to start, and which posts will be most directly relevant to their perspective:
|
If you are… |
Your role might be… |
Start with… |
|
Technology leaders |
CTOs, enterprise architects, Salesforce platform leads |
Posts 1–2, 5, 8–9 |
|
Business leaders |
Heads of retail, commercial, and private banking; lending executives |
Posts 1, 3–6, 10 |
|
Compliance & risk leaders |
Chief Compliance Officers, Chief Risk Officers, audit teams |
Posts 1, 7, 9 |
|
Salesforce practitioners |
Admins, developers, architects working in FSC environments |
Posts 2–5, 8–9 |
|
All readers |
Anyone assessing whether and when to migrate to FSC Core |
Posts 1, 9–10 |
That said, every post is written to be accessible to a thoughtful reader without deep Salesforce expertise. Where technical concepts appear, they are explained in context. Where specific regulatory frameworks are referenced, they are grounded in operational banking scenarios rather than abstract compliance language.
Here is what to expect across the full series:
|
# |
Post Title |
What You’ll Get |
|
1 |
The Platform at a Crossroads |
We open with the strategic question every FSC institution should be asking: why are the managed package and FSC Core diverging so quickly, and what does that divergence mean for your institution’s ability to access the next generation of Salesforce capabilities? |
|
2 |
What “On-Platform” Actually Means |
Before you can evaluate the case for FSC Core, you need to understand what is actually different about its architecture. We decode the managed package namespace, explain the constraints it creates, and show what changes when financial data lives on standard Salesforce objects. |
|
3 |
The Data Model Revolution |
Three new objects — Financial Account Party, Financial Account Balance, and Party Relationship Group — represent a fundamental rethinking of how financial relationships are represented in Salesforce. This post explains each one through concrete banking and lending scenarios. |
|
4 |
Households Reimagined |
The Party Relationship Group deserves its own post. We go deep on what the PRG enables that household record types cannot: multi-entity composition, explicit relationship roles, cross-entity rollups, and the Agentforce-ready relationship intelligence that modern banking demands. |
|
5 |
Saying Goodbye to Batch Rollup Lag |
The managed package’s nightly batch rollup is one of the most quietly damaging limitations in financial services CRM. We make the business case for why FSC Core’s Data Processing Engine is not just a performance improvement but a genuinely different way of thinking about financial data freshness. |
|
6 |
Unlocking Agentforce and AI |
Every major AI capability Salesforce is building — Agentforce agents, Data Cloud unified profiles, Einstein relationship intelligence — is designed for the standard object model. We show exactly what managed package institutions are locked out of, and what FSC Core institutions can build today. |
|
7 |
Compliance, Auditability, and Control |
For CCOs and CROs: beneficial ownership documentation, audit trail integrity, field-level security, and regulatory reporting all look meaningfully better on FSC Core’s standard object architecture. We examine five specific compliance areas where the managed package creates friction that FSC Core removes. |
|
8 |
The Integration Advantage |
Open banking APIs, fintech partnerships, core banking modernisation, digital banking platforms — every integration your institution manages pays a namespace tax on the managed package. We quantify that tax and show what the integration landscape looks like without it. |
|
9 |
Building Your Migration Roadmap |
The practical post. A four-phase framework — Assess, Design, Migrate in Waves, Stabilise — with the key decisions, critical watch-outs, and hidden opportunities at each stage. The mindset reframe: migration is not a technical lift, it is an opportunity to build the platform you should have had all along. |
|
10 |
The Institutions That Move First Will Win |
The series closes with a vision post: what financial services on FSC Core looks like at full maturity, the competitive dynamics of the next three to five years, and the clear statement of what separates the institutions that will lead from those that will catch up. |
The ten posts are designed to build on each other. If you read them in order, each post assumes familiarity with the arguments made in the posts before it. The architecture explanation in Post 2 informs the data model discussion in Posts 3 and 4. The data model changes in Posts 3 and 4 make the performance argument in Post 5 more concrete. The compliance post in Post 7 is richer if you have read the data model posts first.
That said, each post is also written to stand alone. If you come to the series through a specific post — because a colleague shared it, or because the compliance topic or the AI topic is what drew you in — you will find the context you need within that post to follow the argument. The series introduction table above can help you navigate to the posts most relevant to your immediate questions.
We will publish one post per week. If you would like to follow the series as it publishes, [add your preferred follow / subscribe call to action here].
We have tried to write this series with intellectual honesty about a topic where there are genuine complexities and legitimate reasons for institutions to move at different speeds. The managed package is not broken. Institutions have built sophisticated, valuable Salesforce environments on it. The case for FSC Core is not “your current platform is failing you” — it is “your current platform is not where the future is being built.”
That is a different kind of argument, and it requires a different kind of response. Not alarm, but clarity. Not urgency for its own sake, but a genuine assessment of what your institution stands to gain by moving now versus later, and what it stands to lose by waiting.