Presentation Notes 01: Apex Wealth Partners
AI-Generated Content — Use for Reference Only
This content is AI-generated and has only been validated by AI review processes. It has NOT been reviewed or validated by certified Salesforce CTAs or human subject matter experts. Do not rely on this content as authoritative or completely accurate. Use it solely as a reference point for your own study and preparation. Always verify architectural recommendations against official Salesforce documentation.
Presentation Context
Format: 15-minute boardroom presentation + 10-minute Q&A Audience: CTO, CCO, VP Wealth Management, VP Retail Banking, External CTA Review Board Goal: Defend your architecture with clear reasoning, trade-off acknowledgment, and stakeholder-aware framing
Opening (1 min)
“I am presenting my recommended architecture for Apex Wealth Partners’ unified client platform — a 24-month program bringing wealth and banking onto a single Salesforce Financial Services Cloud org while enforcing regulatory boundaries.”
Framing sentence: “My design is driven by three priorities: a unified client view for 180,000 accounts, regulatory compliance across SEC, FINRA, SOX, and GLBA, and an integration architecture that processes 2 million records nightly.”
System Landscape (2 min)
- Single Salesforce org with FSC — not two orgs (explain why next)
- MuleSoft Anypoint as middleware — six systems, three protocols, 2M records/night justifies centralized middleware
- Okta for employee SSO; Experience Cloud native identity for client portal — deliberately separate flows
Transition: “Let me address the question I know is top of mind — why a single org?”
Multi-Org Decision (3 min — most important slide)
Three-part argument:
- Business case: 8,000 overlapping clients. Unified view requires data co-location. External objects via Connect break aggregate household reporting.
- Regulatory case: Compliance needs a single query surface. Two orgs = two audit trails, two Event Monitoring streams, doubled compliance cost.
- Operational case: 10-person CoE cannot sustain two orgs — two pipelines, two sandbox sets, two release calendars create permanent overhead.
Acknowledge the trade-off: “Single org makes the Chinese wall harder. I address this with Restriction Rules.”
Security Model and Chinese Wall (3 min)
- Private OWD on Account/Financial Account. Advisors see only their book. Branch staff see only banking clients in their territory.
- Role hierarchy separates wealth and banking into two branches. No cross-branch inheritance.
- Compliance gets View All via Permission Set Group — not through hierarchy (prevents inheritance exploits).
- Chinese wall:
Has_MNPI__cRestriction Rule hides MNPI-flagged records from all users except authorized viewers. Restriction Rules remove access the sharing model would otherwise provide — distinct from sharing rules which grant access. - SOX: segregation of duties in pipeline, quarterly access certifications, CCO approval gates.
Integration Architecture (2 min)
Focus on the two hardest patterns only:
- Custodian batch: 800K records nightly from Schwab/Pershing. MuleSoft picks up files, transforms Pershing’s format, loads to staging, reconciles, then upserts to Financial Holding. Partial failures don’t corrupt loaded data.
- FIS real-time: Synchronous SOAP callout through MuleSoft for on-demand balance inquiry. No transaction data stored in Salesforce — FIS is SOR, volume exceeds storage economics.
If asked about Orion: “Demographics out within 15 minutes via Platform Events. Performance data in nightly. Salesforce wins demographics, Orion wins performance.”
Data Migration and Phasing (2 min)
- 60K banking records from Dynamics. 8K duplicates resolved with survivorship rules (wealth wins investment, banking wins deposits, most recent wins demographics).
- Wealth cleanup in parallel: 15K orphaned accounts, 8.5K departed advisor records, 47 triggers refactored.
- Four phases/24 months. Phase 0: foundation. Phase 1: wealth enhancements. Phase 2: banking before Dynamics renewal. Phase 3: portal after unified data model stable. Each phase has UAT gate with compliance validation.
Governance and Environments (1 min)
- CoE: 10 people, self-sufficient within 18 months.
- Six sandboxes: separate dev for wealth/banking/integration, partial copy QA, full copy staging with CCO gate. All non-prod data masked.
- CI/CD: Salesforce DX + GitHub Actions. 85% coverage enforced. No direct production changes.
Closing (1 min)
“Single FSC org delivers the unified view. Restriction Rules enforce the Chinese wall. MuleSoft handles integration complexity. Four-phase plan gets banking live before contract deadlines while building toward 250,000 clients and $120B AUM. I am ready for your questions.”
Timing Summary
| Segment | Time | Cumulative |
|---|---|---|
| Opening | 1:00 | 1:00 |
| System landscape | 2:00 | 3:00 |
| Multi-org decision | 3:00 | 6:00 |
| Security / Chinese wall | 3:00 | 9:00 |
| Integration | 2:00 | 11:00 |
| Migration / phasing | 2:00 | 13:00 |
| Governance / environments | 1:00 | 14:00 |
| Closing | 1:00 | 15:00 |
Stakeholder Hooks
| Stakeholder | Hook |
|---|---|
| CTO | ”This is defensible to the board because…” |
| CCO | ”The Chinese wall is enforced at the data access layer, not by policy…” |
| VP Wealth | ”Advisors see their book with aggregated AUM in one view…” |
| VP Banking | ”Banking staff see a cross-sell alert without ever seeing portfolio data…” |
| CTA Board | ”I chose X over Y because…” / “The trade-off I accept is…” |