Salesforce + Schwab + Fidelity + Pershing: Transition Platforms with Native Integrations
When an acquisitive RIA evaluates transition platforms, the integration question gets asked in the first 10 minutes of every demo. "Do you integrate with Salesforce? Schwab? Fidelity? Pershing?" The vendor says yes to all four. The slide deck has all four logos. And then, six months into the implementation, your engineering lead discovers that "integrates with" meant a CSV export, a Zapier flow, and a screen-scraping script that breaks every time Fidelity refreshes their portal.
The word "native" matters here, and it is worth being precise. Native integration means a direct API connection, first-party authentication, live bidirectional read/write, and a maintenance model where the platform vendor absorbs the cost of custodian-side changes. Anything else is middleware: bridge tools, RPA scripts, screen-scraping, or per-customer one-off scripts that require your team to babysit when the underlying systems change. Middleware looks like native in a demo and behaves like middleware in production.
This piece is for CTOs and operations directors at acquisitive RIAs who are past the marketing slide and want a concrete framework for evaluating integration depth across Salesforce and the three custodians that hold the majority of RIA AUM. We will get specific about what native looks like for each system, the questions that surface real integration from theater, and the implementation timeline reality.
Why this specific combination of four integrations is the real test
The Salesforce-plus-top-three-custodians integration story is rare because each leg of it is genuinely hard. Salesforce dominates the CRM layer at mid-large RIAs, with Wealthbox stronger at the small-RIA end. Schwab, Fidelity, and Pershing together hold the majority of RIA custodial assets, with Schwab Advisor Services anchoring the largest share after the TD Ameritrade integration completed. An acquisitive RIA picking up advisors from wirehouses, regional broker-dealers, and other RIAs will receive books spread across all three custodians and will need to feed every transition through Salesforce as the system of client record.
A platform that integrates natively with one of these four is common. A platform that integrates natively with all four is rare, and the reason is straightforward: each integration is its own multi-quarter engineering investment, each requires a different developer program, certification path, and ongoing relationship with the partner, and each has a different update cadence that has to be tracked and absorbed. Vendors that claim all four often have one or two truly native and the others stitched together with middleware that the customer is expected to maintain. That gap shows up in production as NIGOs, broken syncs, and stale status data.
The operational difference at scale is significant. Manual data entry between systems is the single largest source of NIGOs at most RIAs, typically responsible for 30 to 50 percent of all custodian rejections. Every time a client's middle initial gets retyped from Salesforce into a Schwab form, every time an account number is transcribed from Pershing's portal into a spreadsheet, you are introducing transcription error that the custodian will catch. Native integration eliminates that re-keying. Data flows from Salesforce into the packet preparation engine into the custodian's submission queue without a human typing the same field twice. The NIGOs that remain are real business exceptions, not transcription errors.
This matters in dollar terms. A 30 to 50 percent reduction in NIGO volume on a pipeline running 15 to 20 concurrent transitions per quarter is the difference between three NIGOs per advisor and one, between three weeks of avoidable rework per quarter and three days. At an industry average of $19B in advisor AUM moving annually across the largest RIA acquirers, the integration layer is not a feature checkbox. It is the largest driver of transition cycle time after the team operating model itself.
What native actually means for Salesforce
Salesforce-native integration has a specific technical meaning that vendors should be able to articulate cleanly. It starts with a managed package distributed through the Salesforce AppExchange. A managed package means the vendor's data model, UI, and business logic install into your Salesforce org as a versioned, supported extension that Salesforce itself reviews. It is not an external app pretending to be Salesforce. The managed package brings custom objects for transition records, advisor records, account records, packet records, and NIGO records, all related back to your existing Salesforce contacts, accounts, and households.
Bidirectional sync of client and household data is essential. The transition platform should read contacts, accounts, and relationship structures from Salesforce when an advisor's book is being onboarded, and write status updates, document references, and audit events back into Salesforce as the transition progresses. The advisor and the operations team should be able to see current transition state inside Salesforce, on the same page where they see the client relationship. A sync that runs nightly and overwrites half your fields is not bidirectional. A sync that runs in real time on event triggers and respects field-level conflict resolution is.
UI surfaces matter. The right Salesforce-native platform delivers Lightning components that render inside Salesforce, so the advisor liaison who lives in Salesforce all day does not have to learn a second application to check transition status. The CCO can build Salesforce reports and dashboards on transition data because the data lives in Salesforce objects, not in an external system accessed through a link. Power users can build Flows on transition events. This is the difference between an integrated tool and a parallel system that happens to exchange data.
Authentication and security have to be enterprise-grade. SSO via SAML or OIDC, federated identity from your Salesforce org, field-level permissions that respect your existing Salesforce profile model, audit logging that ties back to Salesforce user IDs. If your vendor cannot explain how a user provisioned in Salesforce automatically gets the right access in the transition platform, that is a six-month integration project waiting to happen.
The discovery questions are simple. Is the platform listed on AppExchange as a managed package? Can the vendor name 10 production customers running it inside Salesforce? Is the customer's Salesforce org the system of record, or does data live primarily in the vendor's external database? Can the vendor demonstrate a real-time field update flowing from a custodian status change through their platform into a Salesforce account record? Vague answers here mean the integration is shallower than it appears.
What native means for Schwab Advisor Services, Fidelity Wealth Services, and Pershing
Each custodian has its own developer program, its own API surface, and its own integration philosophy. A platform that genuinely supports all three has invested in three distinct partner relationships.
Schwab Advisor Services exposes APIs for advisor-side workflows including account opening, ACATS submission, status retrieval, and document attachment. A natively integrated transition platform should be able to submit a new account application directly to Schwab from the packet preparation engine, pull ACATS status updates as they progress, and attach supporting documents to the Schwab record without an operations specialist logging into Schwab's portal. The integration should survive Schwab form updates because the platform vendor maintains the form library and updates packet generation when Schwab changes a field.
Fidelity Wealth Services has its own advisor portal and developer program. Native integration with Fidelity means similar capabilities to the Schwab story: account opening flows initiated from the platform, ACATS submission and status tracking, document handling, and automatic absorption of Fidelity-side form changes. Fidelity's update cadence and form library differ from Schwab's, which is why a single integration team has to maintain genuine expertise in each custodian's environment rather than treating them as interchangeable.
Pershing, part of BNY Mellon, runs the NetX360 advisor platform. Native integration here means API connectivity to NetX360 for account opening, ACATS, and status retrieval, plus document workflows aligned with Pershing's books and records expectations. Pershing's customer base skews toward broker-dealers more than RIAs, but acquisitive RIAs that pick up advisors from BD platforms will inherit Pershing accounts and need clean integration to move them efficiently.
The questions to ask are concrete. Can the vendor show production traffic flowing through each custodian's API in their own admin tools? What is the platform's track record on absorbing custodian form changes without customer impact? How many production customers are running each custodian integration today? What happens when a custodian's API has a planned maintenance window or an unplanned outage? A vendor that has run real production traffic for at least four quarters across all three custodians can answer these in detail. A vendor that has not will give general answers about reliability and uptime that do not address the specific failure modes.
ACATS-to-NIGO automatic mapping is the operational test of integration depth. When a custodian rejects a packet, the rejection comes back with a code and a reason. A truly integrated platform parses that response, categorizes it as a structured NIGO, routes it to the right specialist's queue, and updates the transition record in Salesforce automatically. A shallow integration drops the rejection into an email inbox or a generic exception queue and asks a human to interpret it. The first model resolves NIGOs in hours. The second resolves them in days.
The implementation timeline reality, and what slips when
Vendors will quote 6 to 8 weeks for a managed-package Salesforce deployment. That number is roughly correct for the platform itself: install the package, configure custom objects, map fields to your existing Salesforce schema, set up profiles and permissions, run user acceptance testing. The 6 to 10 week range is realistic when your Salesforce admin is engaged, your data model is documented, and you do not have unusual customizations that conflict with the managed package's namespace. If your Salesforce instance has heavy custom code, expect 10 to 12 weeks.
Per-custodian integration is typically 2 to 4 weeks of incremental work per custodian, assuming the vendor already has sandbox access to that custodian's developer program. The bulk of the time is your team certifying that the integration behaves as expected in your specific configuration, not the vendor building anything new. If the vendor does not have an existing sandbox relationship with one of the custodians, add 4 to 8 weeks to that leg for partner program enrollment.
Full multi-custodian production readiness, with all four integrations live and your operations team trained, typically runs 12 to 16 weeks end-to-end. That timeline assumes you run integrations in parallel rather than serially. A serial approach, where you go live with Salesforce first, then Schwab, then Fidelity, then Pershing, can stretch to 24 weeks and is almost always the wrong sequencing because your operations team has to adapt their workflow three separate times instead of once.
The slip points are predictable. Salesforce data quality issues, where existing contact records have inconsistent formatting or missing fields, surface in week 4 or 5 of the Salesforce integration and can add 2 weeks of cleanup. Custodian sandbox access delays, where the vendor has applied for sandbox credentials but the custodian's partner team takes longer than expected to provision, can add 3 to 6 weeks to a custodian integration. User acceptance testing surprises, where the platform behaves correctly but your team's existing workflows assumed something different, add 1 to 3 weeks of process redesign that should have happened upstream of the implementation.
The way to compress this honestly is to do the upstream work before the implementation starts. Audit your Salesforce data quality and remediate before week one. Confirm the vendor has live production traffic on each custodian's API before you sign. Map your current operational workflow stage-by-stage with the vendor so the configuration matches your real process. Schedule UAT with your actual operations specialists, not just managers, so workflow surprises surface early. A 12-week implementation that lands cleanly on schedule is the result of 4 weeks of upstream preparation, not of pressure during the build.
What the integrated stack lets you operate that the disconnected stack cannot
Once Salesforce, Schwab, Fidelity, and Pershing are all genuinely connected, the operating model changes in ways that are difficult to articulate in a demo and impossible to ignore in production. Client data flows from Salesforce into packet preparation without re-keying, which eliminates the largest single category of NIGO. Status updates flow from each custodian back through the platform into Salesforce, which means the advisor liaison checking on Mrs. Patel's account transfer at 2pm sees the status as of 2pm, not as of last night's batch job. The CCO reviews exceptions in one place rather than logging into Schwab, Fidelity, Pershing, and Salesforce sequentially to assemble a picture of where things stand.
The operations team can specialize meaningfully because the platform abstracts the custodian-specific knowledge. An intake specialist does not need to be expert in all three custodians' form libraries because the platform applies the right forms automatically based on which custodian the account is destined for. A NIGO resolver works from a unified exception queue that has already classified each rejection by custodian, by reason code, and by likely fix. Compliance signs off in Salesforce, knowing that the underlying records in each custodian's system are accurately reflected.
The advisor experience changes too. The advisor who is transitioning her book wants visibility into where each of her client accounts is in the process, not a separate login for each custodian's portal. The integrated stack lets the advisor see her full book in one view, filtered by status, with the same data the operations team is working from. That visibility is itself a recruiting feature. Advisors talk to peers about transition quality, and a clean, transparent process is one of the strongest signals an acquisitive RIA can send.
There is a quieter benefit that matters at scale. Reporting and analytics work because the data is structured and lives in known systems. When the CEO asks how the recruiting class of Q2 is performing relative to Q1, the operations director can answer with a Salesforce dashboard backed by real transition data, not by an ops analyst's manually assembled spreadsheet. When the board wants to see NIGO trends by custodian over the last four quarters, the data is queryable. When regulators ask for a complete audit trail on any transition, the record exists in Salesforce, tied to specific user actions and custodian responses, with timestamps that match.
The disconnected stack appears cheaper because each component is bought independently and the integration cost is hidden in operations payroll. The integrated stack is more expensive in license fees and pays itself back in two ways: in the cycle time reduction that captures fees faster on advisor books that are already worth $19B annually across the largest recruiters, and in the operational headcount that does not have to scale linearly with transition volume. The platform is the leverage point. Salesforce plus the top three custodians is what the platform has to plug into to actually deliver that leverage.
Frequently Asked Questions
How do we tell whether a vendor's Salesforce integration is truly native versus a Zapier-style middleware connection?
Three quick checks. First, is the platform a managed package listed on the Salesforce AppExchange with current reviews and version history? Second, does the platform install custom objects directly into your Salesforce org, or does data live in the vendor's external database with a sync? Third, can the vendor demo a real-time event flowing from Salesforce to their platform and back without a polling delay? Native passes all three. Middleware fails at least one.
Do we need integration with all three custodians, or can we start with just Schwab?
Depends on your acquisition pipeline. If you are recruiting exclusively from Schwab-custodied books, Schwab-only integration is acceptable as a starting point. If you are picking up advisors from wirehouses and broker-dealers, you will inherit Schwab, Fidelity, and Pershing accounts in mixed proportions and need all three. Most acquisitive RIAs at scale need all three custodian integrations within 12 to 18 months of starting their transition platform program.
What is the typical cycle time improvement from moving from middleware to native integration?
The biggest single source of improvement is NIGO reduction from eliminated re-keying, typically 30 to 50 percent fewer NIGOs. That translates to roughly 1 to 2 weeks of average cycle time reduction per transition, depending on book complexity. On top of that, real-time status sync eliminates 3 to 5 business days of waiting for batch updates between systems. Combined improvement is usually 2 to 3 weeks of cycle time per transition.
How does a managed-package deployment interact with our existing Salesforce customizations?
Managed packages live in their own namespace, which means they do not collide with your existing custom objects, fields, or Apex code. They reference your standard Salesforce objects like Contact and Account through standard relationships. The risk surface is in your custom triggers or Flows that run on standard objects, which may need to be reviewed for compatibility. A 1 to 2 week Salesforce admin review before installation is standard.
What happens to our integration when Schwab, Fidelity, or Pershing updates their forms or APIs?
With a native integration, the platform vendor absorbs the change. Their integration team monitors custodian release notes, updates the form library or API client, and pushes the update to all customers without customer-side configuration. With middleware or RPA, your team has to detect the change, often after a NIGO surge tells you something is wrong, and either fix it yourself or wait for the middleware vendor to release a patch. This difference is the single largest operational reason to insist on native integration.
Should our Salesforce org be the system of record, or should the transition platform be?
Salesforce should remain the system of record for client relationships, household structures, and ongoing advisor management. The transition platform is the system of record for the operational workflow during the 60 to 90 days a transition is active. Once a transition closes, the relationship and account records live permanently in Salesforce, with the transition workflow records archived in the platform for audit purposes. This split keeps each system focused on what it does well.
How do we evaluate vendor claims about ACATS automation?
Ask to see a live ACATS submission flow from packet preparation through custodian acceptance, with the rejection path included. A real ACATS integration handles the full lifecycle: structured submission, status polling, rejection parsing into NIGO categories, automatic routing to a resolver, and resubmission. A weak integration handles only the submission and dumps everything else into an email inbox. The rejection-handling path is the test.
What is the realistic total implementation timeline for Salesforce plus three custodian integrations?
Twelve to sixteen weeks for full multi-custodian production readiness, assuming parallel implementation rather than serial. The Salesforce managed package takes 6 to 10 weeks. Each custodian integration takes 2 to 4 weeks of incremental work, run in parallel with each other. User acceptance testing and operations team training overlap the final 2 to 3 weeks. Serial implementation, one custodian at a time, can stretch to 24 weeks and is rarely the right choice operationally.
Related: Meeting Assistant · Advisor Transitions Platform
