Explanation:

This is a two-part requirement: 1) Universal access to Person Accounts, 2) Restricted access to Financial Accounts. The solution involves a combination of object-level permissions and sharing settings.

Why A and B are Correct:

A. Grant users access to the Financial Account object with permission set
Correct (Object-Level Control). Access to the Financial Account object itself (FinServ__FinancialAccount__c) is controlled by object permissions in profiles and permission sets. To restrict access to "only specific users," the admin must not grant Financial Account permissions to all profiles. Instead, they should create a permission set with Financial Account object permissions (Read, etc.) and assign it only to the specific users who need it.

B. Change Organization-wide Defaults (OWD) sharing on the 'Financial Accounts' object to 'Private'.
Correct (Record-Level Baseline). Setting OWD to Private ensures that by default, no one can see any Financial Account records except the record owner and administrators. This creates a locked-down baseline. Then, access is opened up only through:
- The permission set in A (which grants object-level access).
- Additional sharing mechanisms (like sharing rules, role hierarchy, Compliant Data Sharing) for those permitted users.
This combination ensures users without the permission set see zero Financial Accounts, even if other sharing rules exist.

Why the Other Options Are Incorrect:
C. Change Organization-wide Defaults (OWD) sharing on the 'Person Accounts' object to 'Controlled by Parent'.
Incorrect. "Controlled by Parent" is not a valid OWD setting for the Account object (which Person Accounts are part of). The standard OWD settings are Private, Public Read Only, and Public Read/Write.
Person Account access is typically set to Public Read Only or similar to allow all internal users to see client records, fulfilling the first part of the requirement. Changing it to a restrictive or non-existent setting would break universal access.

D. Change Organization-wide Defaults (OWD) sharing on the 'Financial Accounts' object to 'Public Read/Write'.
Incorrect. This would do the opposite of the requirement. Setting OWD to Public Read/Write would grant all users in the org access to view and edit all Financial Account records, completely eliminating any privacy protection.

Key References & Security Model:
Two-Layer Security:
Object-Level: Can the user see the type of record? (Controlled by Profiles/Permission Sets - A).
Record-Level: Which specific records of that type can the user see? (Baseline controlled by OWD - B, then expanded by sharing rules).

Typical Setup for This Scenario:
Person Account (Account Object): OWD = Public Read Only. Standard User profile includes Read access to Account object.
Financial Account Object: OWD = Private (B). Standard User profile does NOT include Financial Account permissions.
Permission Set (A): Created with "Read" access to FinServ__FinancialAccount__c and assigned only to authorized users (e.g., advisors, managers).

Result: All users see Person Accounts. Only users with the permission set see Financial Accounts, and even they only see records shared with them via other rules.

Summary:
To restrict Financial Account access to specific users while allowing universal Person Account access, the admin must set Financial Account OWD to Private (B) and then use a permission set to grant object access only to authorized users (A).

Explanation:

As of January 2026, Salesforce FSC continues to emphasize its out-of-the-box (OOTB) industry flows to solve common operational bottlenecks in banking.

Why D is correct: The Send Documents flow for Retail Banking is a prebuilt, templated flow designed specifically to streamline the document collection process. It allows agents to initiate document requests directly from within Salesforce, often integrating with e-signature tools (like DocuSign). Because the request and its status are tracked directly in FSC, customer service agents gain a single, consolidated view of what has been sent, what is pending, and what has been received—eliminating the need to check "multiple systems".

Why others are incorrect:
A: While Marketing Cloud can automate communication, it is an external platform that doesn't inherently solve the problem of agents lacking a unified view of document status within the core FSC service console.
B: Apex is a custom code solution. Salesforce's best practice is to always use declarative tools (like prebuilt Flows) before resorting to custom code.
C: Process Builder is a retired tool that has been superseded by Salesforce Flow. Modern solutions should not be built on Process Builder.

Reference
Salesforce provides industry-specialized workflows in the Lightning Flow for FSC package to automate routine banking tasks.
Salesforce Help: Automate Repeatable Tasks with Action Plans and Flows
Salesforce FSC Admin Guide: Track Required Customer Documents

Explanation:

Why B is correct
In Financial Services Cloud (FSC), when you create additional Person Account record types to represent different kinds of “Individuals” (for example, Individual Customer vs Independent Advisor), FSC needs to know how to map those Person Account record types to the FSC “Individual” model used by FSC features and automations.
Salesforce provides this mapping through the Individual Record Type Mapper custom metadata type. You create your new Person Account record types and then add mapping records so FSC recognizes and treats them correctly as Individuals.

Why the other options are wrong

A. Create custom fields on the Person Account object.
Custom fields don’t create or differentiate record types. They may support business logic, but they don’t solve the “two different Person Account record types” requirement.

C. Create a record type on the Contact object.
With Person Accounts, the “person” is represented primarily through the Account (IsPersonAccount = true) record (with a related contact behind the scenes). FSC record type configuration for Individuals is handled via the Individual mapping, not by creating Contact record types for this purpose.

D. Enable “Use Person Account” custom setting.
This setting is used to enable FSC’s Person Account-based behavior in the FSC package, but it doesn’t create or correctly wire up multiple Individual-oriented record types by itself. The specific requirement here is adding two Person Account record types and ensuring FSC recognizes them—handled by the Individual Record Type Mapper.

Key reference
Salesforce Help: Configure Custom Record Types for Individuals (uses Individual Record Type Mapper custom metadata)
Salesforce Developer Docs: IndividualRecordTypeMapper custom metadata type description

Explanation:

Intelligent Need-Based Referrals and Scoring is a native FSC capability that helps bankers prioritize referrals by automatically scoring them based on client needs, likelihood of success, and other criteria.

A. Referral Approval Processes – While referral approvals are part of workflow management, they don't inherently help prioritize or identify the "most promising" referrals.

B. Intelligent Need-Based Referrals and Scoring – Correct. This FSC feature uses data and rules to score and rank referrals, helping bankers focus on high-potential opportunities. It's specifically designed to increase referral conversion rates through intelligent prioritization.

C. Einstein Referral Scoring for Financial Services Cloud – This is a distractor. While Einstein AI capabilities exist in Salesforce, the specific feature name is "Intelligent Need-Based Referrals and Scoring." There isn't a separately named "Einstein Referral Scoring" feature in core FSC.

D. Referral Routing Rules – These help direct referrals to appropriate bankers but don't provide scoring or prioritization intelligence about which referrals are most promising.

References:
Salesforce Help: "Intelligent Need-Based Referrals and Scoring" – describes how this feature analyzes client data to score and prioritize referrals.

Financial Services Cloud Release Notes: "Increase Referral Conversion with Intelligent Scoring" – explains the business value of this capability.

FSC Implementation Guide: "Set Up Referral Scoring" – provides configuration steps for enabling referral prioritization.

Key Concept:
FSC includes industry-specific intelligence features like referral scoring that go beyond basic CRM functionality. This capability uses client data (financial holdings, life events, interactions) to automatically assess referral quality, helping bankers focus on high-value opportunities rather than treating all referrals equally.

Explanation:

In Salesforce Financial Services Cloud, when the Intelligent Need-Based Referrals and Scoring managed extension package is installed, three specific Lead record types are added to the Lead object. This setup is standard for most Financial Services Cloud implementations that use referral features.

Referral
Used for leads originating from internal or external referrals, such as from existing clients or partners. This record type enables scoring, referral-specific fields, and integration with referral dashboards and incentive tracking.

General
A catch-all record type for standard inbound leads that do not fall into referral or specialized categories.

Retirement Planning
A specialized record type for leads related specifically to retirement planning services. This allows tailored page layouts, fields, and processes for a common wealth management use case.

These three record types allow advisors to configure different page layouts, picklist values, and business processes based on the lead source or lead type.

Why not the others?

B. Opportunity ❌
Incorrect. Opportunity is a separate object in Salesforce. Leads can convert into Opportunities, but there is no Opportunity record type on the Lead object.

D. Adjustments ❌
Incorrect. No record type named Adjustments exists on the Lead object in Financial Services Cloud.

References:
Salesforce Help and Trailhead — Intelligent Need-Based Referrals and Scoring setup documentation (lists Referral, General, and Retirement Planning as the Lead record types created by the managed extension package)
Financial Services Cloud implementation guides and Accredited Professional practice exams (commonly test this multi-select question with A, C, and E as the correct answers)