Before an Advisor Move, Check Your Data Access

Start with access, not a vendor list

A prospective firm shows your team a technology diagram. The CRM connects to financial planning. Planning connects to portfolio data. The firm says its APIs will help everything work together.

That may be a useful setup. But before an experienced advisor or team moves, there is another question: which data will you actually be allowed to use, in which systems, and with whose support?

An application programming interface, or API, lets software connect to specified information or functions. It is not a promise that every record, document, or historical field will be available to your team. Official eMoney and Schwab materials describe API capabilities, but they also point to access processes and provider-specific features. [2] [3]

You do not need to become a developer to evaluate this. You need clear answers about authorized access, usable records, and the responsibilities behind the connection.

The integration claim deserves a closer look

Fidelity's 2026 Technology Integrations Pulse Survey found that fewer than one in four respondents described their firm's technology as at least somewhat integrated. The online client survey covered 270 wealth-management professionals from RIA and custody firms, including advisors, executives, operations staff, and other roles. It is a self-reported view of that sample, not a census of every RIA or proof that an API causes better results. [1]

For a team considering a move, the useful implication is to ask what the proposed integration actually includes. A working connection can still leave important questions unanswered. Does it bring current account information into planning, or only open another screen? Which records are included? What needs a separate process?

Treat the diagram as a starting point for questions, not confirmation that your team's information needs are covered.

Ask who can authorize and maintain access

Find out who holds the relevant vendor relationship and who can approve the connection. Is access controlled by the receiving firm, a custodian, a technology provider, or more than one of them? Which permissions would your advisor, service, and operations roles receive?

In its October 2025 developer-site announcement, eMoney described guides covering the steps from requesting access to making an authenticated API call, alongside endpoint documentation and a change log. That is evidence of a documented development process, not a statement that every advisor can independently enable every connection. [2]

Ask the receiving firm to identify the administrator and support owner for your proposed setup. Who can approve a change, resolve a permissions problem, or arrange vendor assistance? If the person who built the integration leaves, who maintains it?

Do not solve an access question by asking someone to share credentials. The firm should explain an approved process and the roles responsible for it.

Check the scope of the specific connection

A familiar vendor name does not tell you which functions the receiving firm has enabled. Ask for the current documentation or an explanation from the people responsible for the integration. Separate what is available today from what is planned.

Schwab's API page describes connections to its proprietary Schwab Advisor Center and tells firms to confirm specific features with their provider. Its disclosures say API integration is available through Schwab OpenView Gateway, provided by Performance Technologies, Inc., and that its integration solutions involve accounts custodied at Charles Schwab & Co. It also notes that not all listed third-party providers have integration agreements. [3]

Those distinctions matter. A connection associated with one custodian should not be assumed to cover every account your team serves. A provider's presence on a website should not replace confirmation of the particular feature you need.

Ask the same questions of any proposed planning, CRM, or portfolio connection. Which systems exchange data, which way does it flow, and what information remains outside that process? You are checking the setup offered to your team, not ranking vendors in the abstract.

Test completeness with a fictional record

Use a fictional household or a vendor-approved test record. Include the kinds of information your team relies on, such as household relationships, account identifiers, planning assumptions, notes, tasks, and relevant history. Ask the receiving firm to show what appears in each system and what does not.

A current balance appearing in a planning tool does not answer whether meeting notes or older documents will be available through another process. Ask separately about each important record type. Do not assume an API endpoint is a complete export or an archival service.

Check how the firm handles mismatched identifiers, missing fields, and conflicting values. Which system is treated as the source for a particular field? Who notices an exception, and who resolves it? Ask how your team would know that a record was incomplete before relying on it.

This is a data-completeness test, not permission to move real records. Do not export current-firm client information for a demonstration unless the use is properly authorized.

Separate migration from ongoing access

Make two lists. One covers information that may need to be established or migrated through an approved transition process. The other covers information your team needs to use after the move. The people and permissions involved may differ.

Ask what preparation is allowed before any resignation or transition. Qualified legal and compliance professionals should determine which records may be used or disclosed and how client communications should be handled. Technical ability to download a file is not an answer to those questions.

The SEC's Regulation S-P amendments require covered institutions to maintain written incident-response policies for unauthorized access to or use of customer information. That is a firm-level safeguard requirement, not permission for an individual advisor to carry records to another firm. Applicability and the obligations in your situation need qualified review. [4]

For ongoing access, ask who approves new connections and how access is changed when a colleague's responsibilities change. A useful integration should have an understandable control process, not depend on informal exceptions.

Ask about support, cost, and a future departure

Clarify what the receiving firm will pay for and what your practice might be expected to fund. Does the proposed arrangement include setup, vendor access, maintenance, and help when a data connection fails? Ask for the actual terms rather than assuming the integration is included because it appeared in the presentation.

Discuss interruptions too. Schwab's disclosures acknowledge that electronic services may be limited or unavailable during maintenance, upgrades, peak demand, and other conditions. No integration should be treated as continuously available by default. Ask how the firm handles a service interruption and how your team receives an update. [3]

Finally, ask what happens if your role changes or you later leave. Which access ends? What retention obligations apply? Can any information be provided through an authorized process, in what format, and at whose cost? Have the relevant agreements and policies reviewed instead of relying on a broad statement that the data is yours.

Put the answers into a short data-access brief

For each important connection, record its purpose, data scope, approval owner, team permissions, support contact, and unresolved questions. Mark what has been demonstrated and what still needs confirmation. Keep migration requirements separate from ongoing access and future-departure provisions.

Clients choose whether to change advisers or move assets. Agreements, privacy obligations, firm policies, and applicable law can affect a transition. Neither access to an API nor a technically usable export makes client records or AUM portable by default.

A well-connected platform can be attractive. The better career decision comes from understanding the access your team will actually have, the information it can responsibly use, and the people accountable when something does not work.