A bank account is rarely owned by exactly one person in exactly one way. A joint current account has two primary owners. A brokerage account has a custodian who can trade but not withdraw. A trust account has a trustee, multiple beneficiaries, and a settlor who created the trust. A power of attorney can act on the account but is not an owner. A retiree's adult child can be authorised to receive statements but cannot move money.
Financial Account Role (FAR) is the FSC object that captures all of this. It is the junction between Financial Account and Account (Person Account in most cases), and the field that distinguishes one relationship from another is the Role. Salesforce ships seven standard roles. Most implementations need exactly those seven, sometimes plus one or two custom additions, and rarely more.
The seven standard roles
The shipped FSC role list:
- Primary Owner. The person whose name is on the account. The principal legal holder. Most of the time, exactly one Primary Owner per account; for joint accounts, two.
- Joint Owner. A secondary owner with the same legal standing as the primary. Common on couples' current accounts and joint investment accounts.
- Beneficiary. A person designated to receive proceeds when a triggering event occurs. Most common on life insurance, retirement accounts, and trust structures.
- Trustee. A person legally responsible for managing assets in a trust on behalf of beneficiaries. Holds fiduciary duty but does not personally own the assets.
- Power of Attorney (POA). A person authorised to act on behalf of the owner. Scope varies (financial only, medical only, full); the role captures the existence of the authority.
- Authorised User. A person allowed to use the account for specified actions (typically a credit card account where a family member has a card on the same line).
- Custodian. A person who manages an account on behalf of a minor or someone otherwise unable to manage their own affairs. Common on custodial brokerage accounts for children.
Each role has different rights, different access expectations, and different reporting implications. The role-based sharing logic, the consent capture for marketing, and the compliance reporting all hang off this picklist.
How FAR drives access
The default Salesforce sharing model does not know about roles. Sharing a Financial Account record with a user opens the record; the user sees everything on it. There is no out-of-the-box way to say "this user can see balance but not transactions" or "this user can see the account but only when they are listed as a Joint Owner".
FSC layers role-aware sharing on top through Compliant Data Sharing (CDS). CDS lets an admin configure sharing rules that follow the FAR junction: an advisor granted access to clients with role X gets specific access patterns to those clients' Financial Accounts.
Three access patterns are common:
Full access for Primary and Joint Owners. The owner can see everything. The advisor managing the owner relationship can see everything. Routine.
Read-only for Beneficiaries. The beneficiary can see the account exists, can see the beneficiary designation, but cannot see balance or transactions. CDS rules expose only the FAR record and the high-level account metadata.
Scoped access for Power of Attorney. The POA can see balances and act on transactions within the scope of the authority. The scope is usually captured in a custom field on the FAR record. CDS exposes the account fully when the scope is "Full Financial Authority" and partially when the scope is narrower.
Implementations that skip CDS and try to model role-based access through manual sharing rules invariably drift. The configuration sprawl is too large to maintain by hand. CDS pays back its complexity inside the first major access-pattern change.
When to extend the role list
The temptation to add custom roles is constant. Resist it for cases that fit a standard role with a custom field. Indulge it for cases that are structurally different.
Three legitimate extensions Sapota has built on past FSC engagements:
Estate Executor. The Salesforce standard list does not include executor. For wealth-management orgs that handle estate transitions, Executor needs explicit modelling because the workflow at the death of an account holder differs from POA, Trustee, and Beneficiary.
Investment Advisor. A non-employee licensed advisor who manages a client's investment account. Common in multi-RIA setups where one firm holds the relationship and another holds the discretionary authority.
Statement Recipient. A person who receives statements but has no other authority. Common for adult children of elderly parents under structured caregiving arrangements.
Each custom role needs a corresponding access pattern in CDS, a corresponding consent capture for marketing, and a corresponding compliance reporting line. Adding the role to the picklist without these is what produces "ghost role" records that compliance teams have to research 3 years later.
The reporting and compliance lens
The FAR shape is the data foundation for several regulatory reports.
Beneficial Ownership reporting. Anti-money-laundering rules in most jurisdictions require banks to know who ultimately owns and controls each account. Beneficial Ownership is computed from the FAR list: Primary Owner, Joint Owner, Trustee, certain Beneficiaries. The compliance team builds reports filtered on the FAR Role field.
Sanctions and PEP screening. Politically Exposed Person (PEP) and sanctions screening run against every individual associated with an account, not just the Primary Owner. The FAR records define the screening universe.
Estate and succession reporting. When a Primary Owner dies, the Beneficiary, Trustee, and Executor relationships drive the account transition workflow. Without clean FAR data, the succession process is manual reconstruction from documents.
Each of these reports depends on the FAR data being accurate at the moment the report runs. Implementations that treat FAR as a "set it once at account opening" pattern produce reports that are correct only for new accounts. Periodic FAR review processes, often built as Action Plans, keep the data current.
FAR and Compliant Data Sharing together
The FAR junction object and Compliant Data Sharing (CDS) work as a unit. FAR captures the relationship; CDS enforces the access. Neither is sufficient on its own.
The setup pattern that works:
- Build the FAR data model with the seven standard roles plus any organisation-specific extensions.
- Build CDS rules that map each role to the access pattern advisors and operations teams need.
- Build Action Plan templates that drive periodic FAR review (typically annual) to catch role changes the bank was not told about (deaths, divorces, custody changes).
- Build a custom report or dashboard that surfaces FAR-record changes for compliance audit.
- Build a custom integration to the bank's MDM and core banking system so FAR changes flow bidirectionally.
The last point matters more than it sounds. FAR is the record of who can do what with which account. If the bank's core banking system has a different view of the same relationships, the FSC layer will eventually be wrong. The integration must be bidirectional or one side will drift.
The early-stage common mistake
The most common FAR mistake on FSC implementations: launching with only the Primary Owner role populated.
The pattern arises naturally. The custodian system reports only the Primary Owner field. The initial data load creates one FAR record per account, all with Role = Primary Owner. The implementation goes live. 6 months later, the compliance team asks for Beneficial Ownership reports and discovers the Trustee and Beneficiary roles are empty.
The fix is a structured back-fill. Joint Owner fills from the custodian's joint-account flag. Beneficiary fills from the beneficiary-designation forms the bank already has on paper. Trustee fills from trust-account documentation. The back-fill is months of work, all of which was avoidable by getting the FAR model right at go-live.
Designing the FAR model and CDS rules for an FSC rollout? Sapota's Salesforce team, certified on Financial Services Cloud Accredited Professional (AP-208), runs FAR architecture, CDS configuration, and compliance reporting design on every FSC engagement. Get in touch ->
See the Salesforce service page for the wider team.
