For financial institutions, compliance is not a feature request. It is a condition of operation. The regulatory frameworks governing banking and lending — the Bank Secrecy Act, Anti-Money Laundering requirements, Know Your Customer obligations, the Community Reinvestment Act, fair lending rules, data privacy regulations, and the examination standards set by federal and state banking regulators — touch every dimension of how a bank or lender manages customer data, documents decisions, and demonstrates control over its processes.
Against that backdrop, the choice of CRM architecture is not a purely technical decision. It is a governance decision. The data model your institution uses to represent client relationships, the audit trail mechanisms built into your platform, the access controls governing who can see and modify sensitive financial data, and the ability to produce clean, structured data in response to regulatory inquiries and examination requests — all of these are shaped by whether your institution runs FSC on the managed package or on FSC Core.
This post examines five specific areas where FSC Core’s standard object architecture produces a meaningfully stronger compliance and governance posture than the managed package — and where the managed package’s architectural constraints create compliance risks that are easy to underestimate until an examiner asks a question your platform cannot cleanly answer.
Your CRM architecture is part of your compliance infrastructure. The question is whether it is helping you demonstrate control or asking you to explain workarounds.
Few compliance requirements in banking and lending have grown more demanding in recent years than beneficial ownership documentation. FinCEN’s Customer Due Diligence rule, FATF guidance on ultimate beneficial ownership, and the Corporate Transparency Act’s reporting requirements have collectively elevated beneficial ownership from a due diligence checkbox to a structured data obligation — one that regulators increasingly expect to see documented in a queryable, auditable form.
The FSC managed package’s two-field ownership model — Primary Owner and Joint Owner — was not designed with beneficial ownership documentation in mind. When a commercial banking client is a business entity with multiple principals, when a trust has a trustee and several beneficiaries, or when a lending relationship involves a guarantor structure with layered entity ownership, the two-field model cannot capture the full ownership picture as structured data. Compliance teams working on managed package implementations have typically handled this through custom fields, custom objects, notes, or document attachments — none of which are as easily queryable, auditable, or demonstrable to an examiner as structured object data.
FSC Core’s Financial Account Party model changes this entirely. Every ownership relationship is a record: structured, typed with an explicit party role, queryable via standard SOQL, and included in standard Salesforce reporting. A beneficial ownership inquiry from an examiner can be answered with a report — not with a manual process of cross-referencing custom fields and document repositories.
|
Compliance Scenario: BSA Examination — Beneficial Ownership Documentation |
|
During a BSA examination, an examiner requests documentation of beneficial ownership for a sample of 50 commercial accounts opened in the past 12 months. The examiner wants to see the name, ownership percentage, and role of each beneficial owner for each account, along with the date the information was collected and the identity of the banker who completed the onboarding. Managed Package: Beneficial ownership data is stored in a combination of custom fields, free-text notes, and attached PDF forms. Assembling the requested documentation requires manual retrieval for each account. Some records are incomplete because the two-field model prompted bankers to document only the primary and joint owners. The examination team spends two days preparing the response. FSC Core: Financial Account Party records capture each beneficial owner with their role, the relationship start date, and the creating user. A single Salesforce report filtered by account opening date and party role produces the complete dataset in minutes. The examination response is accurate, complete, and produced from native structured data — demonstrating both the quality of the documentation and the maturity of the institution’s data governance. |
Know Your Customer compliance requires financial institutions to document not just who their customers are, but the process by which they verified that identity, assessed risk, and made onboarding decisions. Regulators increasingly expect that process to be systematic, consistent, and evidenced — not dependent on individual banker judgment about what to document and where to store it.
The managed package supports basic task-based KYC workflows through Action Plans — structured checklists that assign tasks to team members and track completion. Action Plans are a useful tool, and they remain available in FSC Core as well. But the compliance value of KYC workflows is significantly enhanced when the underlying data captured during the process is structured, standardized, and stored in standard objects that support downstream analysis and reporting.
FSC Core’s standard object model enables more sophisticated KYC workflow automation in several ways. The Financial Account Party records that capture beneficial ownership information are created and updated as part of the onboarding workflow, not as a separate documentation step. OmniScript-guided onboarding flows built on FSC Core standard objects create a consistent, structured path through the KYC process for every customer type — ensuring that the data collected meets the institution’s CDD requirements before the workflow can be completed. And as Post 6 described, Agentforce agents can assist with KYC data gathering and verification steps, with every action logged against standard Salesforce objects.
The compliance benefit is not just efficiency — it is consistency and completeness. When every onboarding follows the same OmniScript-guided path, the risk of incomplete KYC documentation due to banker variation is systematically reduced. When examiners review the process, they see a structured workflow with structured outputs, not a collection of banker-specific documentation practices.
Compliance is not just about having the right data. It is about having a process that reliably produces the right data, every time, for every customer.
Field History Tracking on Managed Package Objects
Salesforce’s Field History Tracking mechanism is the primary tool for maintaining an audit trail of data changes in a Salesforce org. When enabled on a field, Field History Tracking records every change to that field: the old value, the new value, the user who made the change, and the timestamp. For financial institutions, this is the CRM-level audit trail that supports both internal controls and regulatory examination.
Field History Tracking works on managed package objects — but with an important caveat. The schema of managed package objects is controlled by Salesforce as the publisher. When Salesforce releases a new version of the FSC managed package, field names, field types, and object structures can change in ways that affect how Field History Tracking records are stored and interpreted. An institution’s audit trail for a managed package field is, in effect, dependent on the continued consistency of a schema it does not control.
This is not a hypothetical risk. Managed package upgrades have historically required institutions to review and sometimes reconstruct audit trail configurations after schema changes. The prefix change from FAR to FAP for Financial Account Party record names introduced in Spring 2025 is a recent example: any institution with custom queries, report filters, or audit trail processes built on the FAR prefix had to review and update those configurations after the upgrade.
Audit Trail Integrity on FSC Core
On FSC Core, the schema of standard objects is governed by the Salesforce platform release cycle, not by a managed package publisher. Standard object field structures are changed only through the formal Salesforce release process, with advance notice to customers and backward compatibility maintained wherever possible. The institution’s Field History Tracking configuration is built on a schema it can predict and control.
More importantly, on FSC Core, the institution has full control over its own org’s object schema. Custom fields, custom objects, and custom relationships added to FSC Core standard objects are entirely under the institution’s governance. Field History Tracking configurations for custom fields are not subject to any external publisher’s upgrade decisions.
For a Chief Compliance Officer or Chief Risk Officer thinking about the audit trail integrity requirements of their Salesforce environment, this distinction matters. A managed package introduces an external dependency into the schema governance of your compliance-critical data. FSC Core removes that dependency.
|
Regulatory Scenario: Audit Trail Review During Fair Lending Examination |
|
A fair lending examination requires documentation of every change to a loan application record’s decision fields over a 24-month period, including the user who made each change and whether any changes were made after the initial decision was recorded. Managed Package: Field History Tracking on the relevant managed package fields captures the required data. However, a managed package upgrade 14 months ago changed the internal field identifier for one of the tracked fields. The audit trail has a gap during the period immediately following the upgrade while the new field identifier was being tracked. Reconstructing the complete 24-month history requires combining records from two field identifiers and explaining the gap to the examiner. FSC Core: Field History Tracking on standard FSC Core fields captures a clean, continuous record with no schema-change interruptions. The 24-month history is producible from a single report. The examination response demonstrates clean data governance with no explanatory footnotes about managed package upgrade impacts. |
Financial institutions handle sensitive data categories that require careful access controls: Social Security numbers, Tax Identification Numbers, account numbers, credit scores, beneficial ownership details, and personal financial information subject to privacy regulations including Gramm-Leach-Bliley Act requirements. Managing access to this data at the field level — ensuring that only authorized roles can view or modify sensitive fields — is a foundational data governance requirement.
Salesforce supports field-level security through Profile and Permission Set configurations, and Salesforce Shield adds platform encryption for particularly sensitive fields. On the managed package, field-level security and encryption work — but with constraints. Salesforce has documented that on the FSC managed package, platform encryption is supported only for the Name and Financial Account Number fields on managed objects. Extending encryption to additional sensitive fields on managed objects requires custom development or acceptance of the limitation.
On FSC Core, standard objects support Salesforce Shield platform encryption across a broader range of fields without the managed package’s constraints. The institution’s data security team can apply field-level encryption to sensitive financial data fields as part of a consistent, platform-governed security architecture — without needing to work around managed package limitations or build custom encryption handling for fields that fall outside the managed package’s supported encryption scope.
For institutions operating under regulatory frameworks that specify data encryption requirements — whether from banking regulators, state privacy laws, or contractual obligations with data partners — the broader encryption support in FSC Core is a meaningful governance improvement.
A persistent operational burden for compliance teams at managed package institutions is the complexity of building and maintaining regulatory reports in Salesforce. Reports that query financial account data, ownership relationships, balance history, and household structures must reference namespace-prefixed field names throughout. SOQL queries used by integration partners, data warehouse feeds, and compliance analytics tools must account for the FinServ__ prefix on every managed package field.
This is not an insurmountable problem — institutions manage it every day. But it is friction that compounds over time: more complex report formulas, more brittle SOQL queries, more documentation required to explain the data model to new team members and external auditors, and more surface area for errors when managed package upgrades change field names or structures.
FSC Core’s standard object model eliminates the namespace from every report, query, and data pipeline. A SOQL query for Financial Account data reads like a standard Salesforce query — accessible to any Salesforce developer or administrator without specialized knowledge of the managed package architecture. Compliance reports are simpler to build, easier to validate, and more straightforward to explain to examiners and auditors who may not be Salesforce specialists.
There is also a data quality dimension to this simplification. When the data model is easier to understand and query, it is easier to validate. Compliance teams running data quality audits, reconciliation checks, and pre-examination data reviews work more efficiently on FSC Core’s clean standard object model than on the managed package’s namespace-layered equivalent. Errors are easier to find, easier to trace, and easier to correct.
Clean data models produce clean audit trails. Clean audit trails produce confident examination responses. FSC Core gives compliance teams a foundation they can trust.
The table below maps key compliance and governance capabilities across the two architectures:
|
Compliance Area |
FSC Managed Package |
FSC Core |
|
Beneficial ownership |
Two-field ownership model limits structured capture of multi-party ownership roles |
Financial Account Party records capture unlimited owners with explicit, queryable roles — directly satisfying beneficial ownership documentation requirements |
|
KYC workflow automation |
Action Plans support basic task checklists; no native structured role data for KYC fields |
Structured party role data enables Agentforce-assisted KYC workflows; OmniScript guides for onboarding built on standard objects |
|
AML transaction alerts |
No native balance history; alerts dependent on external system data feeds |
Financial Account Balance history native in Salesforce; DPE-triggered alerts on balance patterns without leaving the platform |
|
Field-level encryption |
Encryption supported only for Name and Financial Account Number fields on managed objects |
Standard object field encryption supports a broader range of sensitive fields with consistent governance across the platform |
|
Audit trail integrity |
Field History Tracking on managed package fields; publisher schema changes can affect audit logs |
Field History Tracking on standard objects; schema fully under institutional control; no publisher-initiated changes that affect audit records |
|
Data residency control |
Managed package schema governed by Salesforce; limited control over field-level data handling |
Standard object schema fully owned by the institution; data residency and handling controls applied without namespace constraints |
|
Regulatory reporting |
Reports on managed package objects require namespace-aware field references; more brittle |
Standard SOQL and reporting on clean standard objects; regulatory report queries are simpler, more maintainable, and namespace-free |
|
Exam-readiness |
Demonstrating data model accuracy in exams requires explaining managed package architecture |
Standard object model aligns with examiner expectations; cleaner documentation of data governance controls |
The arguments in this post are aimed specifically at the leaders responsible for compliance and risk governance in banking and lending institutions. The technical details of managed package namespaces and standard object architectures may not be your daily concern — but the compliance implications of those architectural choices are.
The questions worth asking of your Salesforce team are straightforward: Can we produce a complete beneficial ownership report for any account in minutes? Does our audit trail for regulated data fields have any gaps or dependencies on external package upgrades? Are there sensitive data fields in our FSC implementation that cannot be encrypted due to managed package constraints? Do our regulatory reports require specialized knowledge of namespace-prefixed field names that makes them harder to validate and more brittle to maintain?
If the answers to any of those questions are uncomfortable, the managed package architecture is a contributing factor. FSC Core does not eliminate compliance risk — no technology platform does. But it removes several architectural sources of compliance friction that the managed package introduces, and it gives compliance and risk teams a cleaner, more governable foundation for the data management obligations of a regulated financial institution.
Post 9 in this series will address how institutions can approach the migration from managed package to FSC Core — including how to use the migration process as an opportunity to improve data quality, strengthen governance structures, and enter the new architecture with a cleaner compliance posture than the one they are leaving behind.
PREVIOUS IN THE SERIES
Post 6: Unlocking Agentforce and AI for Financial Services — Why Core Is the Required Foundation
NEXT IN THE SERIES
Post 8: The Integration Advantage — Open Banking, Fintechs, and the Core Platform
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.