Advisor Production Mapping: OSJ-Tiered Orchestration of Disparate Asset Data
Top-producing financial advisors were invisible to marketing, buried in a flat CRM with no production data attached. We pulled disparate DST/DTCC asset feeds into custom Salesforce objects and mapped them to a tiered OSJ-to-Rep hierarchy. Verified AUM now triggers automated expansion workflows.
Executive Summary
Context
An Enterprise FinTech provider needed its 10,000+ advisor database segmented by verified production levels and OSJ affiliation.
What We Built
A custom data orchestration layer in Salesforce that aggregates external asset feeds and maps them to a three-tier OSJ-to-Rep hierarchy.
Tech Stack
- Salesforce Financial Services Cloud (FSC), DST/DTCC Data Feeds, Custom Apex Aggregation Triggers.
Not a fit for firms selling to individual RIAs or direct-to-consumer (D2C) wealth platforms without tiered oversight structures.
The Challenge
The client's database was a flat list of advisors. Nothing showed which "Office of Supervisory Jurisdiction" (OSJ) each advisor belonged to, or what their actual production levels were. "High-Touch ABM" was impossible: marketing couldn't tell high-value producers from inactive reps. The DST/DTCC data feeds, which hold the truth of an advisor's assets, sat in a siloed compliance database, completely disconnected from the Salesforce CRM the sales and growth teams used.
Our Approach
We engineered a custom "Production Aggregator" within Salesforce. First, custom lookup relationships mapped the legacy Home Office -> OSJ -> Rep hierarchy so reporting rolls up properly. Second, we built a data ingestion pipeline that sanitized external asset feeds and mapped them to the individual rep records. Every advisor got a "Production Score." Finally, OSJ-level reporting gave Home Office executives a dashboard view of which regions were adopting the platform and which were lagging behind. That view turned usage data into a "retention and recruitment" tool.
Impact
Production-Based Segmentation
Marketing can now launch hyper-targeted campaigns based on verified AUM tiers. "Top Producers" get white-glove outreach. "Low Producers" move into high-efficiency automated nurtures.
OSJ Performance Visibility
The sales team got a "Heat Map" of OSJ performance. They now focus recruitment and retention efforts on high-value regional managers rather than individual advisors.
Data-Driven Recruitment Support
The CRM now works as a strategic recruitment asset rather than a simple contact list. It shows exactly how platform adoption correlates with rep productivity across different OSJs.
Custom objects in Salesforce store the raw asset feed data, keeping the standard "Account" and "Contact" records clean. Apex triggers summarize those assets into a single "Current AUM" field on the Contact record. Segmentation stays easy.
A recursive hierarchy structure allows "N-tier" OSJ relationships. That matters because a regional OSJ might oversee several sub-offices, each with its own group of advisors. The model matches that reality.
"AUM Milestones" are automated Salesforce flows. They notify an Account Executive the moment a rep's mapped assets cross a certain threshold, e.g., moving from $50M to $100M AUM, and trigger a "Success/Expansion" outreach.
A data orchestration framework ingesting raw DST/DTCC asset feeds into Salesforce Financial Services Cloud (FSC). An Apex Trigger layer strips sensitive PII and creates a Production Aggregate, mapping AUM to a tiered OSJ-to-Rep hierarchy to enable automated advisor expansion workflows.
FAQ
A "Historical Entity Mapping" field handles this. When a rep moves, the assets follow the Rep record. The legacy OSJ keeps the "Historical Production" data for compliance and "Books and Records" purposes. Both Sales and Compliance stakeholders get what they need.
The data ingestion layer strips out sensitive client-level PII (Personally Identifiable Information) before anything hits the marketing-accessible layers of the CRM. Marketing sees the "Aggregated Asset Value." Compliance-sensitive data stays restricted to the protected Back-Office objects.
